Understanding the MVC Application Structure
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.10. ASP.NET MVC projects by default have six top-level directories, shown in Table 1.1.
Table 1.1: Default Top-Level Directories
| 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) |
| /Content | Where you put CSS and image files, and other non-dynamic/non-JavaScript content |
| /App_Data | Where you store data files you want to read/write |
What if I don't like that directory structure?
ASP.NET MVC does not require this structure. In fact, developers working on large applications will typically partition the application across multiple projects to make it more manageable (for example, data model classes often go in a separate class library project from the web application). The default project structure, however, does provide a nice default directory convention that you can use to keep your application concerns clean.
Note the following about these files and directories. When you expand:
- The /Controllers directory, you'll find that Visual Studio added two Controller classes (Figure 1.11)—HomeController and AccountController—by default to the project.
- The /Views directory, you'll find that three subdirectories—/Account, /Home, and /Shared—as well as several template files within them, were also added to the project by default (Figure 1.12).
- The /Content and /Scripts directories, you'll find a Site.css file that is used to style all HTML on the site, as well as JavaScript libraries that can enable jQuery support within the application (Figure 1.13).
- The MvcMusicStore.Tests project, you'll find two classes that contain unit tests for your Controller classes (see Figure 1.14).
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 and Conventions
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.”
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:
- Controllers
- Models
- Views
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:
- Each Controller's class name ends with Controller—ProductController, HomeController, and so on, and lives in the Controllers directory.
- There is a single Views directory for all the Views of your application.
- Views that Controllers use live in a subdirectory of the Views main directory and are named according to the controller name (minus the Controller suffix). For example, the views for the ProductController discussed earlier would live in /Views/Product.
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.
Conventions Simplify Communication
You write code to communicate. You're speaking to two very different audiences:
- You need to clearly and unambiguously communicate instructions to the computer for execution
- You want developers to be able to navigate and read your code for later maintenance, debugging, and enhancement
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).