Are unit test classes in an ASP.NET MVC web project a good example?

Question

I am studying TDD. I know about dependency injection, in which you place class dependencies in constructor parameters and pass them, passing default implementations from the default constructor, for example:

public AccountController() : this( RepositoryFactory.Users()) { } public AccountController( IUserRepository oUserRepository) { m_oUserRepository = oUserRepository; } 

RepositoryFactory is a simple static class that returns selected implementations for the current assembly.

But the ASP.NET web application project does not do this by default; instead, the DI takes the form of public properties that are assigned in the object initializer in the test class, for example; from AccountController.cs:

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

And in the test class AccountControllerTest.cs:

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

So, now my AccountController class has two approaches to dependency injection. Which one should I use? Constructor inlining or public properties?

Turning on the mouse constructor ...

Is using ASP.NET MVC publicly available because you need to provide a specific way to enter the constructor, and the basic "create new" web application should be shared as a starting point?

Answer 1

The examples in ASP.NET MVC are great demonstrations of how not to use DI .

First of all, using the default constructor, as well as the overloaded constructor, is ambiguous : does the class manage its own dependencies or does it get them from the outside? Apparently, he cannot decide.

Secondly, the default implementation implies a tight connection , because you cannot create a new instance of the default implementation without reference to it. However, the whole point of DI is to enable loose communication .

Unfortunately, we often see this idiom. In my book, I call it Bastard Injection anti-pattern ; I took a name from one of Oren Eini / Ayende Rahien on many stubborn blogs where he is looking at a very similar example .

In general, I recommend using Designer Injections in the vast majority of cases. It is simple to implement and has very strong semantics: it forces the consumer to provide an instance of the dependency, effectively stating that the dependency is mandatory.

Nesting , on the other hand, implies that the dependency is optional, since the compiler does not force you to assign a value. In most cases, dependencies are not optional, so using this template should be rare.

Answer 2

Take a look at the structuremap . You're right ... constructor injection is the preferred DI / IoC method. Check out this article by Martin Fowler . Hope this helps you.