ASP中的依赖注入展示和DependencyResolverasp.net MVC 3
本文关键字：DependencyResolverasp net MVC 依赖 注入 ASP | 更新日期: 2023-09-27 17:54:43
我有一个服务(AccountService)，它有大约八个方法。其中一种方法是发送电子邮件。我有另一个服务(EmailService)，这是构造函数注入到AccountService。
我想知道是否有必要这样做，因为感觉每次我向一个方法添加一个依赖的功能时，我都必须改变我所有的测试，我正在模拟构造函数的依赖。这让人感觉DI实际上让修改东西变得更困难，而不是更容易。
所以我正在考虑在我的控制器动作中使用DependencyResolver，它调用AccountService来获取EmailService并将其传递进去。但是，这会影响我的考试吗?
我该如何测试使用依赖解析器的控制器动作?假设account服务是通过ninject注入到AccountController的构造函数。
欢呼。
不要在你的控制器中使用DependencyResolver !只需使用它来使用Ninject创建控制器(参见https://github.com/ninject/ninject.web.mvc/wiki)。其他的都应该由Ninject使用构造函数注入来创建。
实际上，使用适当的DI和遵循SOLID原则的设计进行单元测试是非常容易的。
在测试fixture设置中，您只需要为每个依赖项创建一个(动态)模拟，并使用创建的模拟作为依赖项创建一个被测试对象的实例。这样，您必须为每个类的所有测试调用构造函数一次。
如果测试很难，那不是因为DI，而是因为没有遵循SOLID原则(很可能是单一责任原则)，或者因为糟糕的测试，例如，单元测试使用了依赖的真实实例，而不是模拟，或者在测试fixture设置中做了太多。
您是否考虑过使用Property DI或者有必要将其注入. tor中?顺便说一句:对于您的测试，您是否使用了某种mock框架(例如Moq, RhinoMocks)?