Why are there 2 constructors in the Default Accoun

Question

here's the default AccountController.cs that's generated by the framework.

public class AccountController : Controller
{
    public IFormsAuthentication FormsAuth { get; private set; }
    public IMembershipService MembershipService { get; private set; }

    public AccountController()
        : this(null, null)
    {
    }
    public AccountController(IFormsAuthentication formsAuth, IMembershipService membershipService)
    {
        FormsAuth = formsAuth ?? new FormsAuthenticationService();
        MembershipService = membershipService ?? new AccountMembershipService();

        //---
    }

This is easy to understand.

public AccountController(IFormsAuthentication formsAuth, 
        IMembershipService membershipService)
    {
        FormsAuth = formsAuth ?? new FormsAuthenticationService();
        MembershipService = membershipService ?? new AccountMembershipService();
    }

What's this? What's its purpose? Is it particular to the Account Controller or is it a requirement for other controllers? and, why should I incorporate it in my project?

public AccountController()
        : this(null, null)
    {
    }

They seem to use this type of constructors in two other places.

Thanks for helping

Answer 1

1. If you use a DI framework (like Unity) and you active your controllers via the container, it might not find the dependencies and use the default constructor (in this case).

2. If you would like use use generics, something like ... where T : IController, new() you will need a default constructor.

Answer 2

Another reason for having a default (no parameter) constructor is for Reflection.

The classes in the System.Reflection namespace, together with Type, allow you to obtain information about loaded assemblies and the types defined within them, such as classes, interfaces, and value types. You can also use reflection to create type instances at run time, and to invoke and access them.

There might be times where you need to create a temporary object of that type in order to reflect over it's properties or methods, but don't want or need the overhead of creating a real object - especially if that entails accessing a database or remote service for example.

Answer 3

This is actually an implemenation of the Bastard Injection anti-pattern.

The idea is that Constructor Injection is supported to allow Dependency Injection (DI), while still providing a default constructor for default behavior.

It's really not necessary to have the default constructor, but if you omit it, you must supply a custom IControllerFactory, as the DefaultControllerFactory assumes that all Controllers have default constructors.

ASP.NET MVC is built with DI in mind, but I guess that to keep it simple, the Bastard Injection pattern was used for the project template to avoid forcing a specific IControllerFactory upon developers.