ASP.NET MVC Web 项目中的单元测试类是一个很好的例子吗？

Question

我正在学习 TDD。我知道依赖注入，您可以将类的依赖项放在构造函数的参数中并传入它们，从默认构造函数传入默认实现，例如；

public AccountController() : this( RepositoryFactory.Users())
{
}

public AccountController( IUserRepository oUserRepository)
{
 m_oUserRepository = oUserRepository;
}

RepositoryFactory 是一个简单的静态类，它返回为当前构建选择的实现

但默认的 ASP.NET MVC Web 应用程序项目并没有这样做，而是 DI 采用公共属性的形式，这些属性在测试类的对象初始化程序中分配，例如；来自 AccountController.cs ：

protected override void Initialize(RequestContext requestContext)
{
 if (FormsService == null)
  { FormsService = new FormsAuthenticationService(); }
 if (MembershipService == null)
  { MembershipService = new AccountMembershipService(); }

 base.Initialize(requestContext);
}

并且在测试类 AccountControllerTest.cs 中：

private static AccountController GetAccountController()
{
 AccountController controller = new AccountController()
 {
  FormsService = new MockFormsAuthenticationService(),
  MembershipService = new MockMembershipService(),
  Url = new UrlHelper(requestContext),
 };
 //snip
}

所以现在我的 AccountController 类有两种依赖注入的方法。我应该使用哪一个？构造函数注入还是公共属性？

正在考虑构造函数注入...

ASP.NET MVC 使用公共属性是不是因为你需要提供一种特定的方式来注入构造函数，而基本的“新建”Web 应用程序需要通用作为起点？

Answer 1

ASP.NET MVC 中的示例很好地演示了如何不使用 DI。

首先，使用默认构造函数和重载构造函数会引入歧义：类是控制自己的依赖关系，还是从外部获取它们？显然，它不能真正决定。

其次，拥有默认实现会引入紧密耦合，因为您无法在没有引用的情况下创建默认实现的新实例。但是，whole point of DI is to enable loose coupling.

不幸的是，我们经常看到这个成语。在my book 我称之为Bastard Injection 反模式；我从Oren Eini/Ayende Rahien 的许多固执己见的博客文章中的一篇中取名，其中he walks through a very similar example。

作为一般建议，我建议在绝大多数情况下使用构造函数注入。它易于实现并且具有很强的语义：它强制消费者提供依赖的实例，有效地表明依赖是强制性的。

另一方面，

Property Injection 意味着依赖项是可选的，因为编译器不会强制您分配值。在大多数情况下，依赖关系并不是真正可选的，因此应该很少使用这种模式。

Answer 2

看看structuremap。你是对的......构造函数注入是 DI/IoC 的首选方法。看看这个article by Martin Fowler。希望对您有所帮助。