keep calm and organizeIn this post I’ll show my guidelines I use to organize my MVC controllers in These guidelines are open for discussion. I just use these to create solid, maintainable and readable MVC controllers.

Initialize controller with dependency injection

This guideline I don’t only use on an MVC controller but on all complex objects. The initialization of your controller should be easy. The parameters in the controller constructor should give you an overview of all the dependencies and capabilities of your controller. The method body of  your controller should be as easy setting the members of your controllers. Those members i generally make private and read only so they can’t get modified in the controller action methods.

Even for small projects I use dependency injection, because generally small project don’t stay small or simple. For the moment there are a lot of IOC containers that integrate with mvc without breaking a sweat. Just add the correct nuget package and it will work out of the box. In mvc 6 everything will be resolved using the build in IOC container.

Add custom View methods on your controller

Maybe it sounds a bit weird but i always create a custom View method per ViewModel. Your viewmodel will, most of the time, have properties that won’t get posted back to the server. So if you have a validation error in your post method you will need to retrieve the value of those properties if you want to show the current view. This logic I write in a View method that will accept a viewModel as parameter and will return an ActionResult.

public ActionResult Create()
    return View(new CreateCarViewModel());

public ActionResult Create(CreateCarViewModel viewModel)
    if (ModelState.IsValid)
        return RedirectPermanent("http://localhost/");
        return View(viewModel);

ActionResult View(CreateCarViewModel viewModel)
    viewModel.Engines = _engineRepository.GetAll();

    return View(viewModel, "createCarView");

Filling your viewmodels with data

This is a big responsibility for a controller. So how do I organize this? As long as the viewmodel can be initialized with an object initializer, I keep its logic in the controller.

In some occasions I create a custom class that will be responsible for populating a specific viewmodel with data. I do this when I start to notice that my View methods becomes to large or complex. When a viewmodel needs data from a lot of different places or when the data has to transformed using a complex de-normalization or grouping process, I also use this technique.

Don’t add validation code to a controller

controller validationYour mvc controller should not be made responsible to validate your data. It only has one responsibility and that is presenting views (html) to your users. Adding validation logic isn’t just only a bad practice (separation of concerns) but it will clutter the action methods of your controllers and as a result, they will be difficult to read and to understand.

So where to put your validation logic?

You should add it to your back-end (business layer). This way it is centered and it could be used be other applications.

If your logic is specific to your mvc application, you can add validation logic to your viewmodels using the annotation attributes or using the IValidatableObject interface for more complex validation. This way your controllers stays “validation logic” clean.

Action method names

A controller name is just a name?When you are creating simple crud based controllers, i would stay to the default action method name.

  • Index
  • Create
  • Details
  • Edit
  • Delete

If it’s not just simple crud based, your action method should describe what your action should do. Sometimes this can be difficult to achieve but I’m not afraid to use long action names. I’m a firm believer that you don’t need to look in your method body to understand what that piece of code does. So for complex actions, my method names will be long and won’t comply with the code naming conventions but they will be understandable for my fellow developers.

Controllers by workflows

When an mvc application contains certain workflows, I create a controller per workflow. This way you can easily find it in your code and everything that is linked to this workflow is grouped within this controller.  It will also be easier to give your method actions a readable name, because the context is already created by the controller. Your urls will also be much clearer and more understandable for your users.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>