Propagation of events in a collection based project

Question

I have a collection-based project in .NET 4. What I mean is that, I have a master collection, call it "System", which is made up of frames, which are each made up of cards, which are in turn made up of channels. So, it looks like System->Frame->Card->Channel. All these are represented as objects, and there is a Parent-Child relationship between them. Essentially, Channel is only exposed to Card, Card is only exposed to Frame, and Frame is only exposed to System.

Ideally, I would wish to expose methods only from the System class to the outside world. However, there are crucial events that occur in Channel, Card, and Frame classes. Currently, the way I handle them is through propagation. Suppose an event occurred in Channel. This event is first raised in Card, then in Frame, and then finally in System. You can see how this results in a lot of code. But my main concern is not of code, but of performance.

Do you think this propagation effects my performance badly? Is there a way to make it more efficient? What other options do I have? My collections are relatively small. System is 1, Frames < 16, Cards < 256, Channels < 8192. Most of the data is stored in the Channel class, which only has primitive objects within it.

EDITS

Here is the code I have in Card for an event that is raised by a Channel:

protected virtual void OnChannelPropertyChanged(Object sender, PFPropertyChangedEventArgs e)
    {
        try
        {
            EventHandler<PFPropertyChangedEventArgs> handler = ChannelPropertyChanged;
            TestEventArgs_ChannelPropertyChanged = e;
            if (handler != null)
            {
                handler(sender, e);
            }
        }
        catch (Exception ex)
        {
            Milltown.MTCore.mtException mtEx = new Milltown.MTCore.mtException((int)PFExceptions.Exception_Hidden_FuctionLevel, ex,
            PFCommonVariables.ApplicationPlatform, PFCommonVariables.ApplicationDataSource, "PFCard:OnChannelPropertyChanged");
        }
    }

And when I add a Channel to a Card within the Card class, I call:

channel.ChannelPropertyChanged += this.OnChannelPropertyChanged;

Answer 1

The only way to answer whether or not affects your performance would be to test it: try it one way where you propogate the events, then another where you attach directly. See which is faster.

That being said, I can't imagine that you're going to find much--if any--measurable impact on performance when you have a few sequential delegate invocations instead of just one. Yes, delegates are slightly slower to invoke than actual methods, so, all things being equal, adding more levels of indirection has a bigger impact than the same level with regular method calls, but this smells of premature optimization.

Your approach is what I would recommend if someone asked how to do what you're after. Go with it unless it's a problem.

EDIT

In response to your comment on another answer, I wanted to expand. C# events have what's called "property syntax". If implemented explicitly in a class, it looks something like this:

private EventHandler eventDelegate;

public event EventHandler MyEvent
{
    add { eventDelegate += value; }
    remove { eventDelegate -= value; }
}

(Actually, it uses Delegate.Combine, but that's immaterial here)

When you attach to an event, it actually calls the add code, passing in the delegate to attach as value; the same is true for remove.

When you use the shorthand event syntax like this:

public event EventHandler MyEvent;

It actually generates code under the covers that's very similar to what I posted above. However, if you make it explicit, you can do whatever you like in the add and remove handlers. This means that you can redirect the target delegate somewhere else. In the case of the other answer, it's redirecting the delegate to a child object.

This will work if and only if the following are true:

1. There is a 1:1 correlation between parent and child, and the related object won't change
2. Exposing a reference to the child object (as object) is acceptable

If you have multiple children, it's technically possible to do (you could just loop through and attach to all of them in the add and remove all of them in remove), but is much more difficult to manage. If the related object or the collection of objects can change after the event is attached, then it becomes virtually impossible to coordinate.

Additionally, if your events follow the recommended practices for events (where you pass the triggering object as sender), then because you're attaching the target directly to the child event rather than raising it yourself, then you'll be exposing a reference to the child object through this argument. I have no idea if that's relevant or acceptable to you, but it's something that should be considered.