While working on my side project, I’ve spent a lot of time trying to work out the best design. Keep in mind that this is more of a hobby for me, so I’m not trying to rush to publish a prototype to get VC.
I’ve worked in the enterprise application development space for several years, so I’m plenty familiar with separations of concerns. I realized, however, that there’s no good solution for handling the ancillary, “can the current user do X” and “if the current user does X, then do Y”. I’ve addressed this issue a number of ways in the past, none of which was particularly elegant. For instance, I’ve used AOP for cross-cutting concerns, but I found it too hard to test and not quite explicit enough.
So, I realized that these “meta-domain” concerns really aren’t concerns for the domain objects themselves. For instance, the User entity doesn’t care if a link is displayed on the user profile page based on security. In this case we could have a security manager that deals with this, but what if this decision isn’t just based on security, but also user reputation, user history and user profile settings? Do I suddenly need to couple my view-model to all of these managers/services? Do I have to have all of these redundant dependencies for every page? What if I forget one? How do I easily test what will happen?
These are all questions that I felt lacked a good answer. As a response, I created a library that is capable of registering “events” and “event” handlers. These aren’t traditional events, but more like “domain events” in that their scope is the entire domain.
Now, sure, there are other ways of accomplishing this, but my particular set of requirements calls for multiple actions to take place when certain events are fired. I also need to know if I can execute a given event, which makes them more than just fire-and-forget.
I had several requirements for my design: it had to be easy to use and understand, it had to play well with an IoC container, it had to be testable and it had to be as type-safe as possible. What I came up with seems to have accomplished all of these, though I haven’t put it to use just yet.
Here’s a snippet from one of the tests that illustrates one of the use cases. The AddNew method is defined on the IMockEventHandler interface. This returns a ValidationResult indicating whether or not the AddNew event can be called in the given MockContext based on all IMockEventHandler objects.
1: var result = eventManager.For<IMockEventHandler>()
2: .In( new MockContext() )
3: .Where( x => x.GetType().FullName.Contains( "Mock" ) )
4: .Where( x => x.EventSourceType == null )
5: .Validate( x => x.AddNew( "s" ) );
Typically the Where criteria won’t exist, they’re just there for flexibility.
So from the code snippet you can see some of the opportunities it presents. Say I have the following:
1: public interface IOrder { 2: void ShipOrder( string orderNumber );
3: }
1: public interface IOrderEventHandler { 2: HandlerResult ShipOrder( string orderNumber );
3: }
I expect to call something like this:
1: var result = eventManager.For<IOrderEventHandler>()
2: .In( currentContext )
3: .TryExecute( x => x.ShipOrder( orderNumber ), exec => { 4: currentOrder.ShipOrder( orderNumber );
5: });
This will execute the given code if, and only if, the HandlerResult of the ShipOrder event handler returns HandlerResult.Success. The variable, result, will hold the HandlerResult so I can take action based on the result (throw an exception, rollback a transaction, etc.)
Now, from the UI perspective, we can have a special UI event handler:
1: public interface IOrderUIEventHandler { 2: HandlerResult DisplayDelete();
3: }
In the backing model, I can lazy load the permissions:
1: public CanDisplayDelete { 2: get { 3: if( _displayDelete == null ) { 4: _displayDelete = false;
5: var result = eventManager.For<IOrderUIEventHandler>()
6: .In( currentContext )
7: .Validate( x => x.DisplayDelete() );
8:
9: if( result == HandlerResult.Success ) { 10: _displayDelete = true;
11: }
12: }
13: return _displayDelete;
14: }
15: }
The key, of course, is for the event manager to be extremely fast. I have tuned the hell out of it from a library persepective, but until I get it in a real application, I don’t have much to go on, but I expect the performance to be negligible. The only area where I need to be cautious is in the design of the event handlers themselves.
I also expect to fine-tune the syntax as it's a little "wordy" for me. I expect that I should be able to optimize the syntax down to a single-line evaluation:
1: eventManager.Validate( x => x.DisplayDelete() );
As I said, once I start using it, I'll be more apt to tune it.
EDIT: To be clear, this design is meant to address a particular problem: there may be a lot of entities interested in particular events and the decisions made may require input from multiple sources. This is not meant to delegate all functionality or business logic to event handlers.