tags:

views:

92

answers:

4

I understand the advantages of using the EventHandler/EventArgs pattern for events, it does however add a lot of overhead.

public class FooBarEventArgs : EventArgs
{
  public int Arg1 { get; set; }
  public string Arg2 { get; set; }
}

public event EventHandler<FooBarEventArgs> FooBar;

Would you break the event pattern for internal events?

internal event Action<int, string> FooBar;

Or would it be better to expose the delegate directly?

internal Action<int, string> FooBar;
A: 

It depends on a lot of things.

  • Granularity: are these internal events on the same scale as the external events, or are the much smaller / more primitive / more frequent?
  • Miscibility: are these internal events the same sort of thing as the external events, such that it would conceptually make sense to intermix them?
  • Support: are you using any supporting features with the event loop (loging, undo, etc.) that you'd like to apply to the internal events as well?

As you can see there isn't a clear right answer; it depends on what your intentions are, and how they fit with the overall application.

MarkusQ
+3  A: 

I think sticking to common patterns is always the best option. Even if it introduces an overhead, it will be easier to understand and maintain the code in the future. You never know who will end up maintaining your code, and you'll do him/her a favor by not using such "shortcuts".

Igor Brejc
+1  A: 

I believe not following the regular event & event handling pattern (using EventHandler/EventHandler) will throw an FxCop/StyleCop violation. If static code analysis, readability and code quality are important to you/your project you should stick with the regular event pattern.

__grover
+1  A: 

Consider it isn't really that much overhead. Also note that the property names will provide extra information for the caller, which is something you don't have when using the Action delegate like that.

eglasius