Table of contents not currently available. Changes from original ALPHA eBook: - Basic Chapter Bookmarks Added - Created CoverPage - Updated this info The following chapters are present: 1,3,4,5,6,7,8,9,10,11,12,13,15,16,17,18 MISSING: (The following chapters are missing between 1 & 18) Chapter 2: This apears to be installing software like MVC 3 etc... So don't worry that it is missing as you can use the web to work it out and the book tells you to refer to chapter 2 if something is not as expected Chapter 14: Appears to be controlers C H A P T E R 1 n n n What’s the Big Idea? ASP.NET MVC is a web development framework from Microsoft that combines the effectiveness and tidiness of model-view-controller (MVC) architecture, the most up-to-date ideas and techniques from agile development, and the best parts of the existing ASP.NET platform. It’s a complete alternative to traditional ASP.NET Web Forms, delivering considerable advantages for all but the most trivial of web development projects. In this chapter, you’ll learn why Microsoft originally created ASP.NET MVC, how it compares to its predecessors and alternatives, and, finally, what’s new in ASP.NET MVC 3. A Brief History of Web Development To understand the distinctive aspects and design goals of ASP.NET MVC, it’s worth considering the history of web development so far—brief though it may be. Over the years, Microsoft’s web development platforms have demonstrated increasing power—and (unfortunately) increasing complexity. As shown in Table 1–1, each new platform tackled the specific shortcomings of its predecessor. Table 1–1. Microsoft’s Lineage of Web Development Technologies Period Technology Strengths Weaknesses Jurassic Common Gateway Interface Simple Runs outside the web (CGI)* server, so is resource- Flexible intensive (spawns a Only option at the time separate OS process per request) Low-level Bronze age Microsoft Internet Database Runs inside web server Just a wrapper for SQL Connector (IDC) queries and templates for formatting result sets 1996 Active Server Pages (ASP) General-purpose Interpreted at runtime Encourages “spaghetti code” 1 CHAPTER 1n WHAT’S THE BIG IDEA? Period Technology Strengths Weaknesses 2002/03 ASP.NET Web Forms 1.0/1.1 Compiled Heavy on bandwidth “Stateful” UI Ugly HTML Vast infrastructure Untestable Encourages object-oriented programming 2005 ASP.NET Web Forms 2.0 2007 ASP.NET AJAX 2008 ASP.NET Web Forms 3.5 2009 ASP.NET MVC 1.0 2010 ASP.NET MVC 2.0 Discussed shortly ASP.NET Web Forms 4.0 2011 ASP.NET MVC 3.0 * CGI is a standard means of connecting a web server to an arbitrary executable program that returns dynamic content. The specification is maintained by the National Center for Supercomputing Applications (NCSA). Traditional ASP.NET Web Forms ASP.NET was a huge shift when it first arrived in 2002. Figure 1-1 illustrates Microsoft’s technology stack as it appeared then. 2 CHAPTER 1n WHAT’S THE BIG IDEA? Figure 1-1. The ASP.NET Web Forms technology stack With Web Forms, Microsoft attempted to hide both HTTP (with its intrinsic statelessness) and HTML (which at the time was unfamiliar to many developers) by modeling the user interface (UI) as a hierarchy of server-side control objects. Each control kept track of its own state across requests (using the View State facility), rendering itself as HTML when needed and automatically connecting client-side events (e.g., a button click) with the corresponding server- side event handler code. In effect, Web Forms is a giant abstraction layer designed to deliver a classic event-driven GUI over the Web. The idea was to make web development feel just the same as Windows Forms development. Developers no longer had to work with a series of independent HTTP requests and responses—we could now think in terms of a stateful UI. We could forget about the Web and its stateless nature and instead build UIs using a drag-and-drop designer and imagine, or at least pretend, that everything was happening on the server. What’s Wrong with ASP.NET Web Forms? Traditional ASP.NET Web Forms was a great idea, but reality proved more complicated. Over time, the use of Web Forms in real-world projects highlighted some shortcomings: View State weight: The actual mechanism for maintaining state across requests (known as View State) results in large blocks of data being transferred between the client and server. This data can reach hundreds of kilobytes in even modest web applications, and it goes back and forth with every request, frustrating site visitors with slower response times and increasing the bandwidth demands of the server. Page life cycle: The mechanism for connecting client-side events with server-side event handler code, part of the page life cycle, can be extraordinarily complicated and delicate. Few developers have success manipulating the control hierarchy at runtime without getting View State errors or finding that some event handlers mysteriously fail to execute. 3 CHAPTER 1n WHAT’S THE BIG IDEA? False sense of separation of concerns: ASP.NET’s code-behind model provides a means to take application code out of its HTML mark-up and into a separate code-behind class. This has been widely applauded for separating logic and presentation, but in reality developers are encouraged to mix presentation code (e.g., manipulating the server-side control tree) with their application logic (e.g., manipulating database data) in these same monstrous code- behind classes. The end result can be fragile and unintelligible. Limited control over HTML: Server controls render themselves as HTML, but not necessarily the HTML you want. Prior to ASP.NET 4, the HTML output usually failed to comply with web standards or make good use of CSS, and server controls generated unpredictable and complex ID values that are hard to access using JavaScript. These problems are reduced in ASP.NET 4, but it can still be tricky to get the HTML you expect. Leaky abstraction: Web Forms tries to hide away HTML and HTTP wherever possible. As you try to implement custom behaviors, you frequently fall out of the abstraction, which forces you to reverse-engineer the post-back event mechanism or perform obtuse acts to make it generate the desired HTML. Plus, all this abstraction can act as a frustrating barrier for competent web developers. Low testability: The designers of ASP.NET could not have anticipated that automated testing would become an essential component of software development. Not surprisingly, the tightly coupled architecture they designed is unsuitable for unit testing. Integration testing can be a challenge too, as we’ll explain in a moment. ASP.NET has kept moving. Version 2.0 added a set of standard application components that can reduce the amount of code you need to write yourself. The AJAX release in 2007 was Microsoft’s response to the Web 2.0/AJAX frenzy of the day, supporting rich client-side interactivity while keeping developers’ lives simple. The most recent release, ASP.NET 4, produces more predictable and standards-compliant HTML markup, but many of the intrinsic limitations remain. Web Development Today Outside Microsoft, web development technology has been progressing rapidly and in several different directions since Web Forms was first released. Aside from AJAX, which we’ve already noted, there have been other major developments. Web Standards and REST The drive for web standards compliance has increased in recent years. Web sites are consumed on a greater variety of devices and browsers than ever before, and web standards (for HTML, CSS, JavaScript, and so forth) remain our one great hope for enjoying a decent browsing experience everywhere—even on the Internet-enabled refrigerator. Modern web platforms can’t afford to ignore the business case and the weight of developer enthusiasm for web- standards compliance. At the same time, REST1 has become the dominant architecture for application interoperability over HTTP, completely overshadowing SOAP (the technology behind ASP.NET’s original approach to Web Services). Today’s 1 Representational State Transfer (REST) describes an application in terms of resources (URIs) representing real-world entities and standard operations (HTTP methods) representing available operations on those resources. For example, you might PUT a new http://www.example.com/ Products/Lawnmower or DELETE http://www.example.com/Customers/Arnold-Smith. 4 CHAPTER 1n WHAT’S THE BIG IDEA? web applications don’t serve just HTML; often they must also serve JSON or XML data to various client technologies including Ajax, Silverlight, and native smartphone applications. This happens naturally with REST, which eliminates the historical distinction between web services and web applications—but requires an approach to HTTP and URL handling that has not easily been supported by ASP.NET Web Forms. Agile and Test-Driven Development It is not just web development that has moved on in the last decade—software development as a whole has shifted towards agile methodologies. This can mean a lot of different things, but it is largely about running software projects as adaptable processes of discovery, resisting the encumbrance and restrictions of excessive forward planning. Enthusiasm for agile methodologies tends to go hand in hand with a particular set of development practices—and tools (usually open source) that promote and assist these practices. Test-driven development (TDD), and its latest reincarnation, behavior-driven development (BDD), are two obvious examples. The idea is to design your software by first describing examples of desired behaviors (known as tests or specifications), so at any time you can verify the stability and correctness of your application by executing your suite of specifications against the implementation.