Programming Microsoft ASP.NET 4 - Dino Esposito [13]
Having AJAX on board without calling for it
One ASP.NET platform that offers testability, simplicity, layering, control, styling, AJAX, and productivity
Nothing is in sight yet at the moment that handles both challenges. So we’re left with using ASP.NET Web Forms the best we can and exploring alternatives. The entire book is devoted to examining ways to write smarter and better ASP.NET Web Forms code. For now, let’s briefly explore two alternatives.
ASP.NET MVC
With version 2 released at the same time as ASP.NET 4 (and version 3 released by the time you read this book), ASP.NET MVC is a good candidate to find a place in the sun in the ASP.NET arena. As clearly stated by Microsoft, ASP.NET MVC is not the successor to Web Forms. It is rather a fully fledged, and fully qualified, alternative to Web Forms. Each framework has its own set of peculiarities. At the end of the day, it is difficult, and also kind of pointless, to try to decide objectively which one is better.
Choosing between ASP.NET Web Forms and ASP.NET MVC is essentially a matter of personal preference, skills, and of course, customer requirements. As an architect or developer, however, it is essential that you understand the structural differences between the frameworks so that you can make a thoughtful decision.
ASP.NET MVC Highlights
ASP.NET MVC is a completely new framework for building ASP.NET applications, designed from the ground up with SoC and testability in mind. With ASP.NET MVC you rediscover the good old taste of the Web—stateless behavior, full control over every single bit of HTML, and total script and CSS freedom.
Processing the request and generating the HTML for the browser are distinct steps and involve distinct components—the controller and the view. The controller gets the request and decides about the action to take. The controller grabs the raw response and communicates it to the view engine for the actual writing onto the browser’s output stream.
In ASP.NET MVC, there’s no dependency on ASPX physical server files. ASPX files might still be part of your project, but they now serve as plain HTML templates that the default view engine uses as a template for creating the HTML response for the browser. When you author an ASP.NET MVC application, you reason in terms of controllers and actions. Each request must be mapped to a pair made by a controller and an action. Executing the action produces data; the view engine gets raw data and a template and produces the final markup (or whatever else it is expected to produce, such as JSON or JavaScript). Figure 1-7 shows the sequence of steps that characterize a typical ASP.NET MVC request.
Figure 1-7. The sequence diagram for an ASP.NET MVC request.
A Runtime for Two
The runtime environment that supports an ASP.NET MVC application is largely the same as in ASP.NET Web Forms, but the request cycle is simpler and more direct. An essential part of the Web Forms model, the page life cycle, is now just an optional implementation detail in ASP.NET MVC. Figure 1-8 compares the run time stack for Web Forms and ASP.NET MVC.
Figure 1-8. The run-time stack of ASP.NET MVC and Web Forms.
As you can see, the run-time stack of ASP.NET MVC is simpler and the difference is due to the lack of a page life cycle. As mentioned earlier, the page life cycle and the entire thick abstraction layer built by Web Forms saves the developer a lot of work.
ASP.NET MVC is closer to the metal, and this has its own side effects. If you need to maintain state, that is up to you. For example, you can store it into Session or Cache, or you can even create, guess what, your own tailor-made, view state–like infrastructure. In the end, the simplicity of ASP.NET MVC is due to different architectural choices rather than to some overhead in the design of the Web Forms model.
So ASP.NET MVC