我有一个服务（AccountService），它有大约八种方法。其中一种方法发送电子邮件。我有另一个服务（EmailService），它是注入AccountService的构造函数。
我想知道是否有必要这样做，因为感觉就像每次我添加一个依赖于方法的功能我必须改变我的所有测试，我在模拟构造函数的依赖项。这感觉就像DI实际上更难改变事物，而不是更容易。
所以我考虑在我的控制器操作中使用DependencyResolver，它调用AccountService来获取EmailService并将其传入。但是，这会影响我的测试吗？
我将如何测试使用依赖项解析程序的控制器操作？鉴于帐户服务是由ninject注入AccountController的构造函数。
干杯。
答案 0 :(得分：5)
不要在Controller中使用DependencyResolver！只需使用它来使用Ninject创建控制器（参见https://github.com/ninject/ninject.web.mvc/wiki）。其他所有内容都应该由Ninject使用构造函数注入创建。
实际上，使用适当的DI进行单元测试以及遵循SOLID原则的设计非常容易。
在测试夹具设置中，除了使用创建的模拟作为依赖项为每个依赖项和被测对象的实例创建（动态）模拟之外，您什么都不做。这样你就必须为每个类的所有测试调用一次构造函数。
如果测试很难，那不是因为DI，而是因为不遵循SOLID原则（很可能是单一责任原则），或者因为不好的测试，例如单元测试使用真实的依赖实例而不是模拟或在测试夹具设置中做太多。
答案 1 :(得分：0)
您是否考虑过使用Property DI或是否有必要将其注入.ctor？ 顺便说一句：对于你的测试你是否使用了一些Mocking Framework（例如Moq，RhinoMocks）？
希望它会对你有所帮助。