Question

What speaks against using the delegates System.Action or System.Func as EventDelegates instead of the classic EventHandler pattern. Will I therefore run into problems?

private bool disposed;

public event Action<IUnitOfWork, IContext> Disposing;

public void Dispose()
{
    if (this.disposed)
    {
        return;
    }

    if (null != this.Disposing)
    {
        this.Disposing(this, this.AttachedContext);
    }

    this.disposed = true;
}

Usage:

unitOfWorkInstance.Disposing += (u, c) => c.Rollback(u); // in my opinion more readable than
unitOfWorkInstance.Disposing += (sender, args) => args.AttachedContext.Rollback(sender as IUnitOfWork);

Answer 1

Well, the code you’ve given there isn’t thread-safe – someone could unsubscribe from the eventhandler after your nullity test and before your call this.Disposing.

But in general, it should work just fine. The downside is that by not following the EventHandler convention, you’re slightly more limited in terms of what can subscribe.

For example, suppose you have a very general event handler method:

public void LogEvent(object sender, EventArgs e)
{
    Console.WriteLine("Event raised");
}

You can use this to subscribe to any event following the normal convention – but not with
your event.

This is a pretty minor downside though. I guess a potentially bigger one is that it may confuse other developers who are expecting to see a conventional event signature.

EDIT: I’ve just remembered that some other libraries may expect the conventional event signature – Reactive Extensions does, for example. IIRC, it’s not impossible to subscribe to other events, just a bit harder.