ASP.NET MVC: Convention over Configuration

For those new to ASP.NET MVC, Microsoft took a "convention over configuration" approach when building MVC web applications. Today, I go over those conventions all of the ASP.NET MVC framework.

Written by Jonathan "JD" Danylko • Last Updated: • MVC •
Convention over Configuration

I would consider this a follow up to the previous post about the differences between WebForms and ASP.NET MVC. Most new MVC developers don't know about the conventions implemented in MVC. So I thought I'd take the time to talk about these conventions.

Convention over Configuration (or coding by convention) is a term that when a convention, or code pattern, is implemented by a tool to match the desired behavior, it behaves as expected without the use of any configuration files.

This makes your coding easier when you know the conventions of where everything is located and you place each component into it's correct location.

Here is a quick list of simple conventions implemented in ASP.NET MVC:

Controllers

  • <class>Controller - This is probably the most obvious when you start out with ASP.NET MVC. If you had a http://localhost/Products/List, you would automatically know that there would be a controller class called ProductsController.cs file in the controller directory. When you create a new controller, by default, it places the word "Controller" as a suffix onto your name. All controllers have the suffix controller added to them.
  • There should be at least one method performing the GET and an optional method performing the post if you are posting data back to the controller.
    • If we have a Products/Index method, we could place nothing on the method (defaulted to GET) or explicitly place a [HttpGet] attribute on the method (Sometimes it's good to distinguish between the two).
    • Optionally, we can have a page POST back from the Products/Index page and it can point to a Products/Index page with a different method signature and an [HttpPost] attribute. You can have your form postback to a completely different method, but if should either redirect to a GET method or return an updated Model back to the user's View.

Routes

  • Default - There will always be a Default route pointing to a main page when your web application starts. Add a minimal amount of routes and consider these like Regular Expressions. They will replace the controller/action/id with a default value. This file is located in the App_Start/RouteConfig.cs.

Views

  • Each View (HTML) page is located in a folder named after the controller's name. Based on the example above, if we have a ProductsController, then under the Views directory, you will see a folder called Products with a List.cshtml file inside that folder.
  • If you have a common .cshtml file (or partial view as we call it in MVC), this can be placed in the Shared folder located under the Views folder.
  • There is always a _Layout.cshtml and this is considered your master page and is located in the Views/Shared folder.

Content

  • Most static content like images and styles go into the Content folder. At the beginning, I was placing most of my scripts in a scripts folder in the content folder, but NuGet started placing scripts into the Scripts directory off the root....so now I keep my Scripts out of my Content folder. :-)

Areas

  • Areas are a way to extend your ASP.NET MVC application even further. When you create an area (right-click on your Visual Studio project and click Add and select Area), all areas will be placed inside an Areas folder at the root of your project and will contain the exact layout of an ASP.NET MVC root folder, complete with controllers, models, and everything else similar. The only difference is that your URL will be longer now. Instead of /controller/action/id and you created a Division area, your URL will look like this: /Division/controller/action/id.

Conclusion

I think I've covered most of the important conventions of an ASP.NET MVC application.

It's amazing the people who I've met who code ASP.NET MVC sites on a daily basis. We take for granted certain conventions while coding. It just becomes second-nature to them without even thinking.

This is what "in the zone" and "convention" means.

Did I miss a convention? Are you taking a convention for granted? Post your comments below.

Did you like this content? Show your support by buying me a coffee.

Buy me a coffee  Buy me a coffee
Picture of Jonathan "JD" Danylko

Jonathan Danylko is a web architect and entrepreneur who's been programming for over 25 years. He's developed websites for small, medium, and Fortune 500 companies since 1996.

He currently works at Insight Enterprises as an Principal Software Engineer Architect.

When asked what he likes to do in his spare time, he replies, "I like to write and I like to code. I also like to write about code."

comments powered by Disqus