我有一个简单的问题。

假设我有一个 .Net 解决方案，有不同的项目，如一些类库(bll、dal 等)和一个可以是 Web 应用程序或 wpf 应用程序的主项目，这没关系。

现在假设我想使用 IoC 容器(如 Windsor、Ninject、Unity 等)来解析验证器、存储库、通用接口(interface)实现等内容。

我把它们放在一起。编译并运行良好。然后，有一天，我添加了一个新服务，并在我的代码中尝试通过 IoC 容器解决它。问题是，我忘记在 IoC 配置中注册它。

一切都编译完毕，应用程序被部署并运行。一切正常，除了页面代码向容器请求该新服务时，容器回答“嘿，我对这项服务一无所知”。

您会记录您的错误，以及用户友好的错误页面。您将去检查错误，查看问题并修复它。很标准。

现在假设我们想要改进流程，并且以某种方式能够在编译时知道我们期望 IoC 容器处理的每个服务是否在代码中正确注册。

如何做到这一点？一件事，单元测​​试被排除在可能的答案之外，我正在寻找另一种方法，如果它确实存在的话。

想法？

编辑 - 经过一些回答和评论，似乎单元测试确实是实现此功能的唯一方法。

我想知道的是，如果单元测试 - 由于任何原因 - 不可能，因此无法在编译时测试 IoC，这是否会阻止您使用 IoC 容器并选择直接实例化所有在你的代码上？我的意思是，您是否认为使用 IoC 和后期绑定(bind)太不安全和太冒险了，并且认为它的优势被这个“缺陷”所超越？

最佳答案

编译器不可能验证整个程序的工作。您的程序编译的事实并不意味着它可以正常工作(即使不使用 IoC)。为此，您将需要自动化测试和手动测试。这并不意味着您不应该尝试让编译器尽可能多地做，但出于这个原因远离 IoC 是不好的，因为 IoC 旨在保持您的应用程序灵活、可测试和可维护。如果没有 IoC，您将无法正确测试您的代码，并且如果没有任何自动化测试，几乎不可能编写任何规模合理的可维护软件。

然而，拥有 IoC 提供的灵 active 确实意味着某些特定代码段所具有的依赖项无法再由编译器验证。所以你需要用另一种方式来做到这一点。

一些 DI 框架允许您验证容器的正确性。 Simple Injector例如，包含一个 Verify() 方法，该方法将简单地遍历所有注册并为每个注册解析一个实例。通过在应用程序启动期间调用此方法(或使用类似方法)，您将在(开发人员)测试期间发现 DI 配置是否有问题，它会阻止应用程序启动。你甚至可以在单元测试中做到这一点。

重要的是，测试 DI 配置不需要太多维护。如果您必须为注册的每种类型添加一个单元测试来验证容器，那么您将失败，这仅仅是因为缺少注册(因此缺少单元测试)将是首先失败的原因。

这为您提供了“几乎”编译时支持。但是，您需要注意应用程序的设计以及将事物连接在一起的方式。以下是一些提示:

1. 远离隐式属性注入(inject)，如果找不到已注册的依赖项，则允许容器跳过注入(inject)属性。这将不允许您的应用程序快速失败，并在以后导致 NullReferenceExceptions。显式属性注入(inject)，即强制容器注入(inject)属性很好，但是，尽可能使用构造函数注入(inject)。
2. 如果可能，显式注册所有根对象。例如，在容器中显式注册所有 ASP.NET MVC Controller 实例。这样容器可以检查从根对象开始的完整依赖图。您应该以自动方式注册所有根对象，例如通过使用反射来查找所有根类型。 MVC3 Integration NuGet Package例如，Simple Injector 包含一个 RegisterMvcControllers 扩展方法，它将为您执行此操作。其他容器的集成包也包含类似的功能。
3. 如果注册根对象不可行或不可行，请在启动期间手动测试每个根对象的创建。例如，对于 ASP.NET Web 表单 Page 类，您可能会从其构造函数中调用容器(因为不幸的是 Page 类必须具有默认构造函数)。这里的关键是使用反射一次找到它们。通过使用反射查找所有 Page 类并对其进行实例化，您将发现(在应用启动或测试期间)您的 DI 配置是否存在问题。
4. 让您的 IoC 容器为您管理的所有服务都有一个公共(public)构造函数。多个构造函数会导致歧义，并可能以不可预知的方式破坏您的应用程序。有multiple constructors is an anti-pattern .
5. 在某些情况下，在应用程序启动期间还无法创建某些依赖项。为确保应用程序可以正常启动并且仍然可以验证 DI 配置的其余部分，请将这些依赖项抽象到代理或抽象工厂后面。

https://stackoverflow.com/questions/9896344/