Require dependency per method call from UnityContainer

So in my current code i'm working on some sort of notification manager.

The idea is that my main BL will use this notification manager per method call. Hence there will probably only be one notification manager (singleton in unity i guess).

When you use the notification manager you can send a notification via SMS\Email\Other. what actually happens is that the notification manager resolves a "INotificationProvidor" which also resides in unity container. This resolve is done by name as in "SMS", "Email", "Other".

Here is a little code snippet:

var notificationProvidor =
    m_Container.Resolve<INotificationProvidor<TResult>>(
        typeOfNotification.ToString());
开发者_如何学Python
ResultMessage<TResult> notificationResult = notificationProvidor
    .SendNotification(source, destination, message, subject);

As you can see the notification manager holds an instance of the container to resolve each one of the "INotificationProvidor"s.

How can i possible remove this need of holding the container in the notification manager? with the following restrictions:

• Not all types of "INotificationProvidor"'s (SMS,email,other) might be registered in the container.
• There will be only one notification manager. (since BL using it will be alive during the course of the application and would receive it from DI)

In short...resolving dependency per method call. :)

I would use Factory pattern. Either create your own with your own interface and implementation. Or I believe many IoC frameworks are clever, when you try to resolve Func<string, INotificationProvidor<TResult>>, they will create the factory method dynamicaly by themselves.

The actualy factory implementation would probably need reference to the container itself, but there is no need for this implementation to be part of your project. It can be part of project, where refference to container is no problem.

I suggest the only way to do it is to use some sort of factory, to resolve INotificationProvider instead of Unity container, in any case you have to hold a reference to something, that will resolve dependencies in runtime.

Here's the factory's interface:

interface IProvidersResolver 
{
    INotificationProvider<TNotification> Resolve<TNotification>();
}

That's how you can use it in NotificationManager:

// here you hold the reference to the resolver
private IProvidersResolver _resolver;

// here you use injected factory to resolve INotificationProvider
void UseResolver()
{
    INotificationProvider<SomeNotification> provider = _resolver.Resole<SomeNotification>();
}

So you hold a reference to IProviderResolver (the factory) only. This is the common practice. Alternatively you can:

1. instantiate NotificationManager for every INotificationProvider<TNotification>
2. pass a reference to the container into NotificationManager

I think you can solve this by having a dependency on an factory which will turn the typeOfNotification into an actual NotificationProvider in the classes which need to be able to get a NotificationPrivider based on a sting. The factory class will get created by the container, and have all of the available notification providers injected into its constructor.

Then you can have the container do all the wiring up for you in the composition root, but have each method get a NotificationProvider based on the string value of typeOfNotification