Question

所以在我目前的代码中，我正在研究某种通知管理器。

这个想法是我的主BL将在每次方法调用时使用此通知管理器。因此，可能只有一个通知管理器（我认为这是统一的单身）。

使用通知管理器时，您可以通过SMS \ Email \ Other发送通知。实际发生的是通知管理器解析了一个“INotificationProvidor”，它也位于统一容器中。此解析通过名称完成，如“SMS”，“电子邮件”，“其他”。

这是一个小代码片段：

var notificationProvidor =
    m_Container.Resolve<INotificationProvidor<TResult>>(
        typeOfNotification.ToString());

ResultMessage<TResult> notificationResult = notificationProvidor
    .SendNotification(source, destination, message, subject);

正如您所见，通知管理器持有容器的实例来解析每个“INotificationProvidor”。

如何才能删除在通知管理器中保存容器的需要？有以下限制：

并非所有类型的“INotificationProvidor”（短信，电子邮件，其他）都可以在容器中注册。
只有一个通知管理器。（因为使用BL的BL在申请过程中会活着并且会从DI收到它）

简而言之......解决每个方法调用的依赖性。：）

Answer 1

我会使用Factory pattern。使用您自己的界面和实现创建自己的。或者我相信很多IoC框架都很聪明，当你尝试解决Func<string, INotificationProvidor<TResult>>时，他们会自己动态地创建工厂方法。

实际工厂实现可能需要引用容器本身，但不需要将此实现作为项目的一部分。它可以是项目的一部分，对容器的引用没有问题。

Answer 2

我建议唯一的方法是使用某种工厂来解析INotificationProvider而不是Unity容器，无论如何你必须持有对某些内容的引用，这将解决运行时的依赖关系。

这是工厂的界面：

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

您可以在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>();
}

因此，您只能引用IProviderResolver（工厂）。这是常见的做法。或者你也可以：

为每个NotificationManager

INotificationProvider<TNotification>

将对容器的引用传递给NotificationManager

Answer 3

我认为您可以通过依赖工厂来解决这个问题，这会将typeOfNotification转换为需要能够根据sting获得NotificationProvider的类中的实际NotificationPrivider。工厂类将由容器创建，并将所有可用的通知提供程序注入其构造函数中。

然后，您可以让容器在合成根中为您完成所有连接，但是根据字符串值NotificationProvider

让每个方法获得typeOfNotification

要求UnityContainer的每个方法调用依赖

3 个答案: