(excerpt from ASP.NET MVC in Action).
Depending on how long you’ve been building web applications on the Microsoft platform, you’ll relate to some or all of the following pain. In the 1990’s, developers built interactive websites using executable programs that ran on a server. These programs (CGI was a common technology at the time) accepted a web request and were responsible for creating an Html response. Templating was ad-hoc, and the programs were difficult to write, debug and test. In the late 1990’s, Microsoft, after a brief stint with Htx templates and Idc connectors, introduced Active Server Pages, or ASP. Active Server Pages brought templating to web applications. The server page was an Html document with dynamic script mixed in. While this was a big step forward from the alternatives, the world soon saw massive server pages with code indecipherable from the markup. In early 2002, along came ASP.NET. ASP.NET was a complete shift for ASP developers because it moved all server page code into a class file and replaced the Html markup with dynamic server controls in an Xml syntax. While performance increased, and the debugging experience improved, new problems arose. The server-side postback event lifecycle caused newsgroups to explode with activity as developer searched for the magic event in which to add those two simple lines of code. Viewstate, while good in theory, broke down as the application scaled with complexity. Simple pages broke 100KB in size, most of which was the Viewstate. Perhaps the greatest sin of the ASP.NET framework was the tight coupling to everything in the System.Web namespace. There was no hope of unit testing any code in the code-behind file, and today we see Page_Load methods that take several trees to print.
The ASP.NET MVC Framework has been introduced to simplify the complex parts of Web Forms while retaining the power and flexibility of ASP.NET. Controlling code is kept in a class separated from hard dependencies, and server pages have morphed into simple views, which are nothing more than Html templates filled in with objects passed in by the controller. The post-back event lifecycle is no more, and viewstate is no unnecessary. In the following chapter, we will walk through your first lines of code built on tops of the ASP.NET MVC Framework. After this primer, you’ll be ready for more advanced topics.
Throughout this chapter, we will take you through creating a new ASP.NET MVC Framework web application project, creating your first routes, controllers, and views. We will comb through the default application and explain each part. Then we will extend it, and you will create your first controller and view.
In this section, we will understand what the MVC pattern is and create our first ASP.NET MVC Web Application. We will focus first on the controller because in the Model-View-Controller triad, the controller is in charge and decides what model objects to use and what views to render. The controller is in charge of coordination and executes first when the web request comes in to the application. The controller is responsible for deciding what response is appropriate for the request.
The MVC pattern is not new. In fact, it is quite old. A core tenet of the MVC pattern is to separate control logic from the view, or a screen. A view is responsible for rendering the user interface. By separating domain logic and decoupling data access calls from the view, the user interface can now stay the same even while logic and data access changes within the application. In figure 1.1, you will see a simple diagram of the model-view-controller triad. Note that the controller has a direct relationship with the view and the model, but the model does not need to know about the controller or the view. The web request will be handled by the controller, and the controller will decide which model objects to use and which view objects to render.
Figure 1.1 The model-view-controller pattern depicted
To begin, we will open up Visual Studio 2008 and create our project. The edition of Visual Studio 2008 makes some difference. You must be using Visual Studio 2008 Professional or a Team Edition sku that has all of the Professional edition’s functionality. The ASP.NET MVC Framework is supported with Visual Web Developer Express as of the Service Pack 1 release, which added web project and class library support. The ASP.NET MVC Framework builds on top of a web application projects, and while it is possible to make it work with Web Sites, the development experience is optimized for use with Web Application Projects.
You must already have the MVC Framework installed to proceed. The MVC Framework is an independent release that builds on .Net 3.5 Service Pack 1. You can also deploy your application by including the MVC Framework assemblies in the /bin folder of your web application if you need to run on a server with only .Net 3.5 SP1 installed. If you are fond of Reflector (Lutz Roeder’s Reflector: http://www.aisto.com/roeder/dotnet/), you want to be sure to familiarize yourself with the System.Web.Mvc namespace in the System.Web.Mvc assembly.
We’ll begin in Visual Studio 2008 Professional by creating a new ASP.NET MVC Web Application project. When you pull up the New Project dialog, make sure you have .Net Framework 3.5 selected. If you have .Net Framework 3.0 or 2.0 selected, Visual Studio will filter the list, and you won’t see the project template for ASP.NET MVC Web Application.
Stay tuned for more: My feed: http://feeds.jeffreypalermo.com/jeffreypalermo
You will also want to pay attention to my co-authors: Ben Scheirman and Jimmy Bogard.