我应该将 IOC 容器的配置从 UI 中抽象出来吗？

Question

我们的团队一直在构建一个 DDD 应用程序，该应用程序具有严格定义的应用程序服务层，该服务层构建为系统的“API”。它负责将域和基础设施中的所有内容整合在一起以完成通用任务。它只使用 DTO 作为输入/输出，因此域永远不会暴露在这一层之外。

现在我们想添加一个依赖注入容器，但我们面临着一些艰难的选择。我们有两个使用应用程序服务来完成工作的客户端应用程序：一个 MVC 2 应用程序和一个 Windows 服务应用程序。传统上，使依赖注入工作的所有配置代码都放在mvc项目中的global.asax文件中，我见过很多这样的例子。问题是 IOC 注册代码随后在 Windows 服务中重复，并针对该平台进行了轻微修改。

我遇到的问题是 DI 要求客户端应用程序知道注册什么以及如何注册，这还要求客户端应用程序引用域和基础设施层。拥有应用程序服务层的整个想法是，这是客户应该了解和交谈的唯一内容。我提出的解决方案是在我的应用程序服务层中创建一个“依赖服务”，客户端将调用一次该服务，并且它将配置 DI 容器，因为它知道需要什么。它还具有允许客户端应用程序注册其自己的附加依赖项的方法。例如，MVC 项目将注册其控制器工厂，Windows 服务将注册其启动类。我想知道这是否不常见，或者我的这个想法是否走错了路。以前有其他人遇到过这个问题吗？

Answer 1

给猫剥皮的方法有很多种；然而，您似乎采取了错误的方法。应用程序的入口点（Global.asax 或 Program.cs）绝对应该是选择要在 IoC 容器中配置的组件的位置。另一方面，您的服务通常不应嵌入任何 IoC 配置知识。我的猜测是您已经遵循了这一原则，但由于重复配置而正在重新检查它。

为了在不重复代码的情况下实现这一点，正如您所描述的，许多 IoC 容器提供了模块化结构，封装了一组相关组件的配置。在 Autofac（和 Ninject IIRC）中，这些被称为“模块” - http://code.google .com/p/autofac/wiki/StructuringWithModules。 Castle Windsor 称它们为“安装程序”，而 StructureMap 称它们为“注册表”。

通过将配置分解为模块，减少了应用程序启动方法中的配置代码量。在您的示例中，为了简化起见，您可以创建三个模块：

• CoreModule
• WebModule
• ServiceProcessModule

CoreModule 将包含在每个执行环境中共享且行为相同的组件的配置。

WebModule 和 ServiceProcessModule 将包含特定于这些环境的组件的注册，以及根据主机进行不同配置的任何共享组件的专门配置。

您的 Web 应用程序启动将类似于：

foo.RegisterModule<CoreModule>();
foo.RegisterModule<WebModule>();
// Resolve root component, run app

虽然服务流程非常相似，但用 WebModule 替换 ServiceProcessModule。

与使用条件代码的静态初始化方法相比，这种配置风格将更好地扩展到许多应用程序入口点和/或许多组件子系统。

希望这有帮助。
缺口

Answer 2

我将一个配置类放入 DDD 或 DomainModel 项目中，并在 UI 中调用该配置类。

public static class IoCConfigurator()
{
    public static void Initialize()
    {
        // your code here
    }
}

在您的 UI 中，您只需调用 Initialize() 方法即可。您可以在 MVC Global.asax 甚至 Windows 服务应用程序中使用它。没有代码重复。

对我来说效果很好。