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

Posted 2023-02-24

【中文标题】IoC 容器，在编译时检查错误

【英文标题】：IoC container, check for errors at compile time

【发布时间】：2012-04-11 09:16:02

【问题描述】：

我有一个简单的问题。

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

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

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

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

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

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

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

想法？

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

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

【问题讨论】：

正如@Chriseyre2000 在他的回答中指出的那样，单元测试是检查 IoC 配置的一种非常有效的方法，因此您可能会重新评估不进行测试的决定。对此的替代方法是手动测试网站中的每个页面是否加载。

这不是一个决定，我想知道除了单元测试之外是否还有另一种一致且可靠的方法来实现这一目标，这是我目前知道的唯一方法。跨度>

为什么不能使用单一方法单元测试？

我在谈论 IoC，我被告知 IoC 不是“编译时安全的”和“单元测试增加了更多的复杂性并且更难维护”。所以我认为我遗漏了一些东西（因为我通常使用 IoC，当事情变得复杂时，我会进行一些测试）并且我在这里询问是否有比我更有经验的人可以告诉我这样做的更好方法，或者确认事实上，IoC 是一种不好的做法，因为它允许您编译但在运行时失败。

【参考方案1】：

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

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

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

【参考方案2】：

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

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

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

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

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

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

【讨论】：

非常感谢您的回答，但我认为您弄错了我试图理解的内容。我不需要检查我注册的服务是否正确解析。我需要检查的是代码请求的每个服务在配置中都有一个注册。我想了解 IoC 是否可以被认为是一种不好或危险的做法，这件事是不能做的。

你不应该从你的代码中请求你的服务。相反，通过构造函数注入注入所有服务并仅解析根对象。这样一来，一个完整的对象图就构建好了，这样你就知道当你的根对象被正确解析时，所有的服务都被正确注册了。

是的，我指的是根对象。

@neeohw，你的评论肯定有很多道理，这也是我近年来开始意识到的。您所指的练习称为纯 DI（即在没有容器的情况下练习 DI）。对于较小的应用程序，我更喜欢使用 Pure DI。对于大型应用程序，我更喜欢 DI 容器提供的功能（如自动注册和约定优于配置）。但是您的里程可能会有所不同。但在松散耦合中是主要部分。是否使用 DI 容器应该是一个实现细节。

【参考方案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 的责任，即使那里没有使用容器。您还可以获得所需的编译时检查。

另外两句：

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

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

【讨论】：

你说得对，我不是在做服务定位器而是做 DI，因为它更具可扩展性和可操作性。我认为服务定位器确实是一种反模式。我倾向于使用带有通用 Resolve 方法的单例容器实例，该方法在内部将使用我选择的 IoC 容器。我要求它解析一个 T 对象，他将实例化它，通过 DI 解决它的依赖关系。我的问题是要理解“IoC 不好，因为你的代码可以编译但可能会被破坏”这句话是否成立，以及是否有替代单元测试的方法（因为测试被认为是复杂的）。

@MatteoMosca：我没有在这里回答这个问题吗？我已经证明你可以在没有单元测试的情况下拥有 IoC 和编译时安全性。

是和不是。我不愿意放弃容器或选择的 IoC 框架来支持这一点。我想知道我的“需要”是否可以在指定的条件下得到满足，在所有的答案和 cmets 之后，答案很明显是否定的，这是我从一开始就想到的。感谢您的帮助。

【参考方案4】：

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

【讨论】：

我完全同意你的看法。这就是我通常会做的事情，我只是想知道是否有可行的替代方案。

“你不能在构建时用编译器测试你所有的代码。这听起来很荒谬。”为什么？编译器是响应指令的程序。一种语言无法提供无法支持用于测试的编译元程序，这并没有内在的原因。

编译器只进行静态代码分析。但不运行它。组件的注册和解析发生在运行时。