The MVC Pattern Meets ASP.NET
From Abstract to Concrete
The Model-View-Presenter pattern is an abstract concept. To bring it in to the realm of an actual software project, that pattern needs to be boiled down into conventions, settings and whatnot. How any pattern gets boiled down to code will differ based on the technology and even the writer of the code. So ASP.NET is not the manifestation of the MVC pattern but a manifestation of it.
As was said in the last piece of the tutorial, MVC is about separating code involved with modeling the domain and code involved with creating a user interface for it. The following describes the conventions they put in place to do that.
The Basic Conventions
The default MVC project has baked in the split between the three nouns of MVC in the "Models", "Views" and "Controllers" folders.
Models
The models folder can be discussed first and put aside as it does not have the importance of the other two in the actual setup (even though logically, as was said before, the separation of "model" code is very important). What should you use the models folder for? You can use it as a place to put your domain model code, for sure, but there is no particular reason to do so; you can put it just as easily in another folder or in a class library project. The latter is my own pattern.
That being said, there is nothing necessarily wrong with the convention. The whole goal is to separate the user interface from the domain model, and separating them into different folders or libraries is a great way to help with that. But do keep in mind that a difference in location on disk does not a separation make. If your domain classes are generating Html so they can be displayed properly, a separation has not been made, regardless of separating files into separate folders.
What we can draw from this is that the "models" folder is a fine convention but there is nothing special about it as far as really separating your user interface code from your domain model is concerned. Using it or deleting it is your choice.
- ASP.NET MVC - Model != BLL owr DAL
Interesting, if brief, discussion on the place of the "models" folder in things.
Views
Unlike the "models" folder, with the "views" you actually get into the core of what MVC offers you. As can be seen in the image on the right, the views are aspx pages.
It is important to note the folder structure. For every controller (which shall be discussed momentarily) there is a corresponding folder with views in it. For example, by default a "HomeController" controller is created. It has a corresponding "Home" folder. As of the typing of this view that you are reading right now, there are six views in the Home folder because the HomeController can return up to six views. The "GettingStarted" folder, though, has seven views, so the GettingStartedController can return up to seven different views.
Since the view is what is the visual expression of the response to a web request, the view is made up of two primary things: Html and code for generating Html. Anything that could be considered domain model should be elsewhere.
Controllers
In ASP.NET MVC, the controllers are responsible for controlling what view is shown or where a user should be redirected. For pages that are just made up of static content (like this one), there is little work for a controller to do. So the controller and method for returning this view that you are looking at right now looks like this:
namespace HowMVCWorks.Controllers
{
public class GettingStartedController : Controller
{
public ActionResult TheMVCPatternMeetsASPNET()
{
return View();
}
}
}
There are two pieces to this. The url for this page directly maps to what you see above. Note:
The last two bits of this Url say two things, a) what controller to use and b) what action on the controller to execute. So "GettingStarted" is the controller, and "TheMVCPatternMeetsASPNET" is the action executed. The action maps to the method by the same name. By returning "View()", the action is saying "return a view with the same name", so the "TheMVCPatternMeetsASPNET" is then displayed to the user.
If you are a user of ASP.NET Webforms, you will notice that this is completely different. As a general rule, if you had "/GettingStarted/TheMVCPatternMeetsASPNET.aspx", you would hit the page that is sitting in the folder called "GettingStarted". Not so with MVC. Through what is called routing, via the Url, the controller and action are specified and the action can return whatever it wants to return. In the above case it just returns a view by the same name; but it does not have to.
So what does the controller do? Primarily it and its actions determine what views are shown. The rules for determining views are as many as your imagination can cook up. By turning the Url into something that maps to a bit of code and not a page, the framework allows you an immense amount of variety on what you return to your user for viewing. In the controller you can also do a number of other things like redirecting and validation (though some would argue it is not the place for the latter), but the most common function is to decide the view to be shown.
Speak Your Mind!
Have something to say? Find a grammatical mistake? Think I said something incorrect? Don't like my perspective? Hate my color scheme? Whatever it is, you can let me know. I would appreciate it if you did.
