Multiple dependencies in an asp.net mvc controller constructor injected

EDIT

It seems to me you basically have these options to reduce constructor dependency count here:

1. Split the controller
2. Add layer in front of the two interfaces
3. Switch to property injection
4. Service locator

#3 and #4 are included for good measure, but they obviously don't actually decrease the dependency count, they only hide them from the constructor. They also have several disadvantages, and I consider service locator especially evil most of the time.

For #1, if you feel your constructor is actually doing two+ jobs, and there is a clean separation where you could split, I would do so. I assume from your responses that you have already considered this, however, and don't want to do this.

That leaves #2 - adding another layer. In this case that would be introducing a factory interface for that particular view model. Naively, I'll name this ICreateTestplanViewModelFactory, but you can name it something more sensical for your app if you wish. A single method on it would construct a CreateTestplanViewModel.

This makes the fact that the data for this view is coming from 2 sources merely an implementation detail. You would wire up an implementation which takes IReleaseDataProvider and ITemplateDataProvider as constructor dependencies.

This is along the lines of what I was suggesting:

public interface IProvideTestPlanSetupModel
{
    CreateTestplanViewModel GetModel();
}

public class TestPlanSetupProvider : IProvideTestPlanSetupModel
{
    private readonly IReleaseDataProvider _releaseDataProvider;
    private readonly ITemplateDataProvider _templateDataProvider;

    public TestPlanSetupProvider(IReleaseDataProvider releaseDataProvider, ITemplateDataProvider templateDataProvider)
    {
        _releaseDataProvider = releaseDataProvider;
        _templateDataProvider = templateDataProvider;
    }

    public CreateTestplanViewModel GetModel()
    {
        var releases = _releaseDataProvider.GetReleases();
        var templates = _templateDataProvider.GetTemplates();

        return new CreateTestplanViewModel(releases, templates);
    }
}

public class TestPlanController : Controller
{
    private readonly IProvideTestPlanSetupModel _testPlanSetupProvider;

    public TestPlanController(IProvideTestPlanSetupModel testPlanSetupProvider)
    {
        _testPlanSetupProvider = testPlanSetupProvider;
    }

    [HttpGet]
    public ActionResult Create()
    {
        var createTestplanViewModel = _testPlanSetupProvider.GetModel();
        return PartialView(createTestplanViewModel);
    }
}

If you don't like constructing a view model anywhere outside the controller, the interface could provide an intermediate object with the same properties that you would copy to the view model. But that is silly, as this combination of data is only relevant for that particular view, which is precisely what the view model is supposed to represent.

On a side note, it seems you are running into pretty common annoyances doing read/write through the same model. Since these issues bother you so, you might investigate CQRS, which perhaps would make you feel less dirty about talking to the database directly for these types of queries and would help you get around the layering labyrinth we all enjoy so much. It seems promising, though I have not yet had the pleasure of test driving it in a production application.

A good general way to decouple your database would be using a unit of work. Here's a great article on from asp.net, as well as another article on MSDN.

In summary, you create a single unit where all of your database/service calls reside and it can handle the database logic. This would reduce the dependancy of your multiple interfaces into a single point, so you would only need to inject 1 class into your controller.

A quote from the MSDN article:

According to Martin Fowler, the Unit of Work pattern "maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems."

In the MVC project:

public class MyController : Controller
{
    private readonly IQueryProcessor _queryProcessor;

    public MyController(IQueryProcessor queryProcessor)
    {
        _queryProcessor = queryProcessor;
    }

    [HttpGet]
    public ActionResult Create()
    {
        var releases = _queryProcessor.Execute(new ProvideReleaseData());
        var templates = _queryProcessor.Execute(new ProvideTemplateData());
        var createTestplanViewModel = AutoMapper.Mapper
            .Map<CreateTestplanViewModel>(releases);
        AutoMapper.Mapper.Map(templates, createTestplanViewModel);
        return PartialView(createTestplanViewModel);
    }
}

You can then constructor inject your current provider implementations into IQueryHandler implementations. The IQueryProcessor is just infrastructure. See this for more info: http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=92

Reply to comments:

It's at the site I linked to. Here's mine:

using System.Diagnostics;
using SimpleInjector;

namespace MyApp.Infrastructure
{
    sealed class SimpleQueryProcessor : IQueryProcessor
    {
        private readonly Container _container;

        public SimpleQueryProcessor(Container container)
        {
            _container = container;
        }

        [DebuggerStepThrough]
        public TResult Execute<TResult>(IDefineQuery<TResult> query)
        {
            var handlerType = typeof(IHandleQueries<,>)
                .MakeGenericType(query.GetType(), typeof(TResult));

            dynamic handler = _container.GetInstance(handlerType);

            return handler.Handle((dynamic)query);
        }
    }
}