0

Following the article: http://www.udidahan.com/2009/06/14/domain-events-salvation/ we can see that DomainEvents implemantation uses DI container 

public static IContainer Container { get; set; }

and then

if(Container != null) {
    foreach(var handler in Container.ResolveAll<Handles<T>>()) handler.Handle(args);
}

Should I integrate DI container inside the same assembly I store domain objects or can I externalize/abstract away the Container.ResolveAll<Handles<T>>()? (In my previous experiences I put all DI-related stuff inside global.asax.cs).

Technically I'm familiar only with Ninject DI container but probably will understand the concept so your advices/illustrations are appreciated.

Thanks!

lexeme
  • 2,915
  • 10
  • 60
  • 125

1 Answers1

2

No it is not necessary. I'd make DomainEvents and its methods non-static and use the container to create it. A decent container will create and initialize the Handles and their dependencies and allow you to call the event handlers without any reference to the container.

The only catch is the registration of the event handlers. For that I use Bootstrapper to call instances of IUnityRegistration and configure UNITY. I started to use CommonServiceLocator to reduce dependencies. And even more recently, I switched to MEF to get rid of the registration classes all together.

bloudraak
  • 5,902
  • 5
  • 37
  • 52
  • Always that complex) Thank you! I'm considering alternatives. Maybe you can suggest one? What I need is to show up messages in context of domain interactions. One: I heard about `SignalR`. Two: http://blogs.taiga.nl/martijn/2011/05/03/keep-your-users-informed-with-asp-net-mvc/ Extra controller logics for the last one.. Have any suggestions? – lexeme May 04 '12 at 10:35
  • SignalR works great but you'll have to write some code to handle and post the events. – bloudraak May 04 '12 at 18:26