CODEWITHSUNDEEP
asp.net-mvc
William
William

Reputation: 330

How Can a Custom Controller Factory Relate to Dependency Injection?

I am reading this article: http://www.codeproject.com/Articles/560798/ASP-NET-MVC-Controller-Dependency-Injection-for-Be The author said that we need to create a custom controller factory cause the default controller factory does not allow parametereless constructor in the controller class in which we are not able to achieve dependency injection. However, I believe that we can create empty constructor with no parameter, and another one which accept parameters and avoid the hassle of creating a custom controller factory as illustrated bellow.

For example in this code: 

public class HomeController : Controller
{
    private readonly ILogger _logger;
    public HomeController()
    {
    } 
    public HomeController(ILogger logger)
    {
        _logger = logger;
    }
}

I can make ILogger variable in the HomeController class public and when I instantiate a HomeController class: 

HomeController controller = new HomeController();

I put: 

controller.logger = whatevervalue

Just like if when I use: 

HomeController controller = new HomeController(whatevervalue);

I believe with the above I can achieve dependency injection.

So why do I need a custom controller factory in the scenario explained above?

Upvotes: 0

Views: 605

Answers (1)

John H
John H

Reputation: 14655

The author said that we need to create a custom controller factory cause the default controller factory does not allow parametereless constructor in the controller class in which we are not able to achieve dependency injection.

I think you may have misunderstood this part of the article. The problem isn't that you can't specify your own constructor, that takes any number of parameters, the problem is that the default controller factory will only call a controller's default constructor. So, to be clear, using your example:

public class HomeController : Controller
{
    private readonly ILogger _logger;
    public HomeController()
    {
    } 
    public HomeController(ILogger logger)
    {
        _logger = logger;
    }
}

When instantiating an instance of HomeController, the default controller factory will always call this constructor:

public HomeController()

and not this one:

public HomeController(ILogger logger)

That means the ILogger instance will always be null.

So now the question becomes, why does the default controller factory only call the default constructor? We can answer that by asking another question: how would the default controller factory know which constructor you wanted it to call? If you say, "well, it could call the one with the most parameters", what would happen if you added a third constructor:

public HomeController(IService service)

HomeController now has three separate constructors, two of which require the same number of arguments. At this point, the default controller factory doesn't have the information it would need to correctly call the constructor you intended it to - it could only guess.

Therefore, the reason you have to implement your own controller factory is to give you a chance to compose the dependencies your controllers need, so you can then invoke the correct constructors for your controllers yourself.

Upvotes: 1

Related Questions