Question

When building complex applications the controllers can start to get unwieldy and very large, which may mean that you split them out into separate controllers. This may not be suitable as it will be reflected in the users experience. Ie. They will see the controller name in the URI.

For example: The default project that ships with MVC has an AccountController, that has actions for login, logoff, register etc.. which seems to violate the Single Responsibility Principle.

So the question is how to resolve this problem and separate out the concerns? An initial response could be just to create separate controllers. Ie.

AccountLoginController

AccountRegisterController

But this would not be a great experience from a customers point of view as it would effect the URI when requesting the resource.

A solution could be to have separate folders for each controller which contains separate class files for the action, each one with a single responsibility like so.

Controllers (folder)
    Account  (folder)
        Register.cs
        Login.cs
        Logout.cs
    AnotherController (folder)
        Actionfile.cs
        Actionfile.cs

The above would separate out the functionality and be highly cohesive.

So, this is a long explanation, but my questions are..

• Has anyone implemented this before?

• If so how do you go about it?

• What are your thoughts regarding this pattern?

Answer 1

It depends on what you mean by single responsibility.

If you mean Authentication as a responsibility, then the out of the box controller is perfect just the way it is. Logging in, Logging out and Registering are all part of the same thing – Authentication. So it makes sense that their code is in the same controller.

If you take the single responsibility principle to the ridiculous extreme, you would never have more than single classes with a single function in a single file.

You have to find a balance between readability/maintainability vs separation of concerns. In this case, it is going too far.

Also, remember that MVC is all about Convention over Configuration, meaning that if you name your controllers and views according to the convention, then they will be discoverable and you will have fewer configuration and routing issues.

Having said that, if you are determined to have a non-conventional Controller Naming convention, so to speak, you can implement your own Controller discovery code which would allow you to use a different convention. From the article linked to above:

public class ControllerConvention : TypeRules, ITypeScanner {
  public void Process(Type type, PluginGraph graph) {
     if (CanBeCast(typeof (IController), type)) {
     string name = type.Name.Replace("Controller", "").ToLower();
      graph.AddType(typeof(IController), type, name);
    }
  }
}