CODEWITHSUNDEEP
asp.net-mvcdependency-injectionsimple-injector
Dmitry A
Dmitry A

Reputation: 21

Dependency injection in MVC + Web API, without interfaces of repository in controller constructor

I am going to use SimpleInjector in MVC.5 application with WebAPI.2

Some methods of MVC controllers will create objects of repositories for CRUD operations. Common approach on the Internet is a using interface of repository in MVC controller, like: 

public class DashboardController : Controller
{
    private readonly IDashboardRepository _repository;

    public DashboardController (IDashboardRepository repository) {
        _repository = repository;
    }

    [HttpPost]
    public JsonData GetInfo()
    {
        return _repository.GetInfo();
    }
...

Similar approach is recommended for WebAPI

However I would not like to pass IDashboardRepository into constructor of controller because of such reasons: I am sure that I will never mock implementation of repository. I do not need separate public interface for repository (current code base has no these interfaces and I'll need to change a lot of files to add them).

My repositories look like: 

public class DashboardFunc : BaseFunc
{
    public DashboardFunc(IApplicationStateProvider sp) :
        base (sp)
    {
    }

    public DashBoardData GetInfo()
    {
        ...

I would like to use such code in controllers of MVC:

public class DashboardController : Controller {

    public DashboardController () {
    }

    [HttpPost]
    public JsonData GetInfo()
    {
        DashboardFunc dashBoard = Global.MvcContainer.GetInstance<DashboardFunc>();
        return Common.ToJson(dashBoard.GetInfo());
    }

The same approach I would like for WebAPI controllers. The only difference is DashboardFunc dashBoard = Global.WebApiContainer.GetInstance();

Is my modification (not using interface of repository in controller) of standard approach OK? Are there any potential issues that can arise in future that can lead architecture change?

Thank you!

Upvotes: 0

Views: 1077

Answers (1)

Steven
Steven

Reputation: 172646

Prevent falling back on calling Global.MvcContainer.GetInstance or any other form of Service Location anti-pattern. There are a lot of downsides to this, even if you don't want to test that code. Downsides of using this are (among others):

  • You lose the ability for the container to change the given implementation for you; it makes your application less flexible.
  • You lose the ability for the container to diagnose the complete object graph for you.
  • You lose the ability to verify the configuration during app start or using an integration test.
  • You lose the ability to spot all the class's dependencies just by looking at a single line of code (the constructor).

So even when you don't need that interface, I would advice to still use constructor injection and do the following:

public class DashboardController : Controller {
    private readonly DashboardFunc dashboard;
    public DashboardController(DashboardFunc dashboard) {
        this.dashboard = dashboard;
    }

    [HttpPost]
    public JsonData GetInfo() {
        return Common.ToJson(this.dashBoard.GetInfo());
    }
}

Upvotes: 4

Related Questions