When you create a new ASP.NET MVC application with Visual Studio, it automatically adds several files and directories to the project, as shown in Figure 1.14. ASP.NET MVC projects created with the Internet application template have eight top-level directories, shown in Table 1.1.
Directory | Purpose |
/Controllers | Where you put Controller classes that handle URL requests |
/Models | Where you put classes that represent and manipulate data and business objects |
/Views | Where you put UI template files that are responsible for rendering output, such as HTML |
/Scripts | Where you put JavaScript library files and scripts (.js) |
/Images | Where you put images used in your site |
/Content | Where you put CSS and other site content, other than scripts and images |
/Filters | Where you put filter code. Filters are an advanced feature, discussed in Chapter 14. |
/App_Data | Where you store data files you want to read/write |
/App_Start | Where you put configuration code for features like Routing, Bundling, and Web API |
Note the following about these files and directories. When you expand:
These default files, added by Visual Studio, provide you with a basic structure for a working application, complete with homepage, about page, account login/logout/registration pages, and an unhandled error page (all wired up and working out of the box).
ASP.NET MVC applications, by default, rely heavily on conventions. This allows developers to avoid having to configure and specify things that can be inferred based on convention.
For instance, MVC uses a convention-based directory-naming structure when resolving View templates, and this convention allows you to omit the location path when referencing views from within a Controller class. By default, ASP.NET MVC looks for the View template file within the Views[ControllerName] directory underneath the application.
MVC is designed around some sensible convention-based defaults that can be overridden as needed. This concept is commonly referred to as “convention over configuration.”
The convention over configuration concept was made popular by Ruby on Rails a few years back, and essentially means:
We know, by now, how to build a web application. Let's roll that experience into the framework so we don't have to configure absolutely everything again.
You can see this concept at work in ASP.NET MVC by taking a look at the three core directories that make the application work:
You don't have to set these folder names in the web.config file — they are just expected to be there by convention. This saves you the work of having to edit an XML file like your web.config, for example, in order to explicitly tell the MVC engine, “You can find my views in the Views directory” — it already knows. It's a convention.
This isn't meant to be magical. Well, actually, it is; it's just not meant to be black magic — the kind of magic where you may not get the outcome you expected (and moreover can actually harm you).
ASP.NET MVC's conventions are pretty straightforward. This is what is expected of your application's structure:
All reusable UI elements live in a similar structure, but in a Shared directory in the Views folder. You'll hear more about views in Chapter 3.
You write code to communicate. You're speaking to two very different audiences:
We've already discussed how convention over configuration helps you to efficiently communicate your intent to MVC. Convention also helps you to clearly communicate with other developers (including your future self). Rather than having to describe every facet of how your applications are structured over and over, following common conventions allows MVC developers worldwide to share a common baseline for all our applications. One of the advantages of software design patterns in general is the way they establish a standard language. Because ASP.NET MVC applies the MVC pattern along with some opinionated conventions, MVC developers can very easily understand code — even in large applications — that they didn't write (or don't remember writing).