单独的容器与一个容器 - Unity答案

【问题标题】：Separate containers vs One container - Unity单独的容器与一个容器 - Unity
【发布时间】：2011-05-01 08:56:03
【问题描述】：

目前，我的团队正在开展一个使用“流程”模型的项目。每个流程都由“步骤”组成，这些步骤可以是每个“IValidationStep”或“ITransactionStep”。在每种情况下，逻辑都是不同的（事务步骤可以回滚）。

这些步骤将通过 Unity 解决。

在我们的项目中，我们将使用可在 Unity 配置中替换的步骤来构建通用验证和事务逻辑。

我们目前正在讨论是分离容器（每个流的容器，由验证过程和事务过程组成）还是将它们全部保存在一个容器中。

我想听听您对将容器与一个容器分开的真实意见。请记住，我们的项目应该可以通过单元测试完全测试。

【问题讨论】：

标签： .net unity-container ioc-container containers

【解决方案1】：

如果您的代码必须是完全可测试的，您的流程可能会通过依赖注入获得所有依赖项（步骤）。在这种情况下，进程将完全独立于 Unity，并且不会引用 UnityContainer。唯一引用UnityContainer 的代码将是逻辑实例化和执行您的流程。这导致我使用命名类型注册的单个 UnityContainer。

【讨论】：

这是我们的考虑之一，因为分离容器意味着 BL 代码必须通过配置部分获取特定的统一容器。因此代码将引用 UnityContainer。
它会使你的代码依赖于具体的统一配置，这是不好的。您的所有单元测试都必须使用统一来正确配置测试过程。
没错，在我看来，似乎在分离 UnityContainers 时，我们需要在我们的测试环境中保存一个 Unity.Config。那么什么时候最好分离 UnityContainers？
我完全同意拉迪斯拉夫的观点。你可以在这里找到更多关于为什么这不好的信息：blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx。

【解决方案2】：

为什么不从一个容器开始并在需要时重构为多个容器，有时你只需要开始，看看你在哪里结束才能知道正确的方法......

【讨论】：

我相信你是对的，但另一个问题是我们目前正在编写其他框架组件以用于该项目和其他项目。一个示例是用于发送通知（电子邮件、短信等）的 NotificationManager。 NotificationManager 使用将在 UnityContainer 中注册的 INotificationProvider。由于它是框架代码，我们需要知道是通过依赖注入获取 INotificationProvider 还是通过 UnityContainer().LoadConfiguration 获取特定的 UnityContainer