ASP.NET MVC 3 中的依赖注入说明和 DependencyResolver？答案

【问题标题】：Dependency Inject exposition and DependencyResolver in ASP.NET MVC 3?ASP.NET MVC 3 中的依赖注入说明和 DependencyResolver？
【发布时间】：2011-05-03 16:18:48
【问题描述】：

我有一个服务（AccountService），它有大约八种方法。其中一种方法发送电子邮件。我有另一个服务 (EmailService)，它是注入 AccountService 的构造函数。

我想知道是否有必要这样做，因为感觉就像每次我向方法添加具有依赖项的功能时，我都必须更改我正在模拟构造函数的依赖项的所有测试。这感觉就像 DI 实际上让改变事情变得更难，而不是更容易。

所以我正在考虑在我的控制器操作中使用 DependencyResolver，它调用 AccountService 来获取 EmailService 并将其传递。但是，这会影响我的测试吗？

我将如何测试使用依赖解析器的控制器操作？假设帐户服务是构造函数，由 ninject 注入到 AccountController 中。

干杯。

【问题讨论】：

标签： c# asp.net-mvc-3 dependency-injection ninject

【解决方案1】：

不要在控制器中使用 DependencyResolver！只需使用它来使用 Ninject 创建控制器（请参阅https://github.com/ninject/ninject.web.mvc/wiki）。其他一切都应该由 Ninject 使用构造函数注入来创建。

实际上，使用适当的 DI 和遵循 SOLID 原则的设计进行单元测试非常容易。

在测试夹具设置中，您除了为每个依赖项创建（动态）模拟和使用创建的模拟作为依赖项的被测对象的实例之外什么也不做。这样你就必须为每个类的所有测试只调用一次构造函数。

如果测试很难，那不是因为 DI，而是因为没有遵循 SOLID 原则（很可能是单一责任原则），或者因为测试不好，例如使用真实依赖实例而不是模拟或在测试夹具设置中做太多事情的单元测试。

【讨论】：

您可能在测试上是对的，我是否应该将模拟设置为我的测试装置中的字段，以便我可以向它们添加功能？有时我会使用假货，例如InMemoryRepository 而不是 Mock>。并不是事情很难测试，只是因为我倾向于尝试使测试原子化，所以所有设置都是在每种情况下。我将检查我的 SRP 服务，并尝试将正在测试的类的初始化移出。感谢您的提示。

【解决方案2】：

您是否考虑过使用 Property DI 或者是否有必要将其注入到 .ctor 中？顺便说一句：对于您的测试，您是否使用某种 Mocking 框架（例如 Moq、RhinoMocks）？

希望对你有所帮助。

【讨论】：

应该避免属性注入，除非依赖是可选的并且服务可以在没有它的情况下生存。