In MVC, with a controller that has multiple constructors, how can I indicate which constructor to call?

Question

It's often the case where I'd like to have multiple constructors in my controllers, since one of the constructors is optimal for manually injecting dependencies during unit testing and the other is optimal for using a IOC container to inject dependencies.

When using the standard service locator or DependencyResolver in MVC 3, is there any way to indicate to the controller factory which constructor to use when activating the controller?

I'd prefer not to use one of the attributes specific to an IOC framework since I want the code to remain independent of the IOC container.

UPDATE: It seems like the majority of the answers indicate its bad practice to have multiple constructors. I don't entirely disagree with this, however, the situation arises as a result of trying to find a good solution to the mapping/conversion layer, which I asked in this question but never got a good answer to.

My code would look like this:

public class SomeController : Controller
{
    private ISomeService _SomeService;
    private IEntityConverter _EntityConverter;

    // this would be used during unit tests when mocking the entity converter 
    public SomeController(ISomeService someService, IEntityConverter entityConverter)
    {
        _SomeService = someService;
        _EntityConverter = entityConverter;
    }

    // this would be used when injecting via an IOC container, where it would be tedious
    // to always specify the implementations for the converters
    public SomeController(ISomeService someService)
        : this(someService, new EntityConverter())
    {
    }

    public ActionResult Index(SomeViewModel someViewModel)
    {
        if (!ModelState.IsValid)
            return View(someViewModel);
        else
        {
            ServiceInput serviceInput = _EntityConverter.ConvertToServiceInput(someViewModel);
            _SomeService.DoSomething(serviceInput);
            return View("Success");
        }
    }
}

In this very simple example, I am using an interface to do conversions between my view models and the entities that are inputs to the service layer.

I'd prefer to use an interface because this conversion can be mocked, rather than if a static method was used. However, I feel like it would be tedious to always have to specify, in the IOC container, what the implementations are for these conversion implementations, since the implementations for these conversion interfaces sit right next to the interfaces.

This may not be the best solution. I'm open to better alternatives.

Answer 1

Don't use multiple constructors. Your classes should have a single definition of what dependencies it needs. That definition lies in the constructor and it should therefore only have 1 public constructor.

I must say I'm not a fan of using mocking frameworks. I found that a good design of my application and my unit tests prevents me from having to use mocking frameworks all together (of course mileage may vary) .

One trick that helps me is allowing null references to be injected into the constructor by not validating the constructor arguments. This is very convenient for unit tests in cases where the class under test does not use the dependency, while in production you would still have the guarantee that null is not injected, since IOC containers will never inject null into a constructor (or at least none of the containers that I know).

Answer 2

Seems like a code-smell that you need an explicit constructor for testing. What if the testing ctor works but the production one doesn't? Seems like a door for bugs to creep in. It would be ideal for tests to use the same path as real clients as far as possible.

What is different between the two ?

Also if you're using some sort of attribute based DI (e.g. like MEF), I'd not be too worried about decoupling. Having an extra attribute (and the corresponding reference) should not be that big a hit... unless you foresee a change in IOC tech in the future.

Answer 3

Maybe I'm misreading your question, but I'm not sure why you would want to test different constructors. The tests should test what's actually going to be used.

For your tests, you ought to mock your dependencies so that they don't need an IoC container.

Using Moq:

Controller:

public SomeController(IService1 service1, IService2 service2)
{
    // Do some cool stuff
}

Test Method:

[Test]
public void Some_Action_In_SomeController_Should_Do_Something()
{
    var service1Mock = new Mock<IService1>();
    var service2Mock = new Mock<IService2>();
    var controller = new SomeController(service1Mock.Object, service2Mock.Object);

    controller.Action();

    // Assert stuff
}

Answer 4

It's all to do with your service locator, you need to configure it where you register your types.

Here is an example of using the default parameterless constructor when using Unity.

Note that by default the service locator will use the most specific constructor (the one with the most parameters)

ServiceLocator.Current.RegisterType<ICache, HttpContextCache>(new InjectionConstructor()); //use default constructor

So why did I need this? It is true I could have made a protected virtual method to resolve HttpContextBase and use extract and override in the test, or otherwise yet another interface with a method that creates the HttpContextBase that can be injected into this class.... or I could just tell unity to use the default constructor.

    private readonly HttpContextBase _httpContextBase;

    public HttpContextCache()
    {
        _httpContextBase = new HttpContextWrapper(HttpContext.Current);
    }

    public HttpContextCache(HttpContextBase httpContextBase)
    {
        _httpContextBase = httpContextBase;
    }

This was a rare case and pretty much all other classes in the project have only one constructor