IoC 容器，在编译时检查错误

Question

我有一个简单的问题。

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

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

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

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

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

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

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

想法？

编辑 - 在一些答案和 cmets 之后，似乎单元测试确实是实现此功能的唯一方法。

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

Answer 1

我使用 roslyn SourceGenerators 编写了一个编译时 IOC 容器，如果您犯了错误，它确实会提供编译时警告和错误。

当然，有些情况只能在运行时提供，但有一些方法可以明确地做到这一点，这意味着如果缺少依赖项，我们仍然可以给你错误。

查看https://github.com/YairHalberstadt/stronginject

Answer 2

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

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

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

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

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

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

Answer 3

我想知道的是，如果单元测试 - 出于任何原因 - 不可能，因此无法在编译时测试 IoC，这是否会阻止您使用 IoC 容器并选择直接实例化所有通过你的代码？

您在此处显示false choice：要么使用容器，要么“在您的代码中直接实例化”。但实际上你仍然可以在没有任何容器的情况下练习依赖注入。而不是这样做：

public void Main(string[] args)
{
    var container = new Container();
    // ... register various types here...

    // only Resolve call in entire application
    var program = container.Resolve<Program>(); 

    program.Run();
}

你只需这样做：

public void Main(string[] args)
{
    var c = new C();
    var b = new B(c);
    var a = new A(b);
    var program = new Program(a);
    program.Run();
}

您仍然可以通过这种方式获得依赖注入的所有优点：组件不会相互创建并且可以保持高度解耦。组件的构建仍然是应用程序composition root 的责任，即使那里没有使用容器。您还可以获得所需的编译时检查。

另外两句：

1. 你标记了你的问题dependency-injection，所以我假设你确实使用了依赖注入而不是服务定位器模式。换句话说，我假设您没有在整个代码中公开和调用容器，这不是必需的，not recommended。如果您使用服务定位器，我的回答将不再有效。请将其视为对服务定位器的打击，而不是对我的回答。 Constructor injection 是更好的选择。

2. 程序员通常会选择使用容器而不是这种手动方法，因为在大型应用程序中，保持实例化的顺序正确是很重要的 - 可能需要大量重新排序，因为您引入某处的单个新依赖项。容器还提供额外的功能，让生活更轻松。

Answer 4

您无法在构建时使用编译器测试所有代码。听起来很荒谬。无论如何，您必须编写不同类型的测试。容器的配置非常适合集成测试。您可以将测试配置为作为构建后事件自动运行，但这会增加构建时间。无论如何，拒绝使用 IoC 容器是一个不好的理由。