我有一个服务 (AccountService)，它有大约八种方法。其中一种方法发送电子邮件。我有另一个服务 (EmailService)，它是注入(inject)到 AccountService 的构造函数。
我想知道是否有必要这样做，因为感觉每次我添加具有对方法的依赖项的功能时，我都必须更改我模拟构造函数依赖项的所有测试。这感觉就像 DI 实际上让改变变得更难，而不是更容易。
所以我考虑在我的 Controller 操作中使用 DependencyResolver，它调用 AccountService 来获取 EmailService 并将其传入。但是，这会影响我的测试吗？
我将如何着手测试使用依赖项解析器的 Controller 操作？鉴于帐户服务是通过 ninject 注入(inject)到 AccountController 中的构造函数。
干杯。
最佳答案
不要在 Controller 中使用 DependencyResolver!只需使用它来使用 Ninject 创建 Controller (参见 https://github.com/ninject/ninject.web.mvc/wiki)。其他一切都应由 Ninject 使用构造函数注入(inject)创建。
实际上，使用适当的 DI 和遵循 SOLID 原则的设计进行单元测试非常容易。
在测试夹具设置中，除了为每个依赖项创建一个(动态)模拟以及使用创建的模拟作为依赖项的被测对象的实例之外，您什么都不做。这样，您必须为每个类的所有测试调用一次构造函数。
如果测试很困难，那不是因为 DI，而是因为没有遵循 SOLID 原则(很可能是单一责任原则)或因为糟糕的测试，例如使用依赖项的真实实例而不是模拟或在测试夹具设置中做太多事情的单元测试。
关于c# - ASP.NET MVC 3 中的依赖注入(inject)说明和 DependencyResolver？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5872519/