A Brief History of Controllers

It's important to remember that the MVC pattern has been around for a long time—decades before this era of modern web applications. When MVC first developed, graphical user interfaces (GUIs) were just a few years old, and the interaction patterns were still evolving. Back then, when the user pressed a key or clicked the screen, a process would “listen,” and that process was the controller. The controller was responsible for receiving that input, interpreting it and updating whatever data class was required (the model), and then notifying the user of changes or program updates (the view, which is covered in more detail in Chapter 3).

In the late 1970s and early 1980s, researchers at Xerox PARC (which, coincidentally, was where the MVC pattern was incubated) began working with the notion of the GUI, wherein users “worked” within a virtual “desktop” environment on which they could click and drag items around. From this came the idea of event-driven programming—executing program actions based on events fired by a user, such as the click of a mouse or the pressing of a key on the keypad.

Over time, as GUIs became the norm, it became clear that the MVC pattern wasn't entirely appropriate for these new systems. In such a system, the GUI components themselves handle user input. If a button was clicked, it was the button that responded to the mouse click, not a controller. The button would, in turn, notify any observers or listeners that it had been clicked. Patterns such as the Model-View-Presenter (MVP) proved to be more relevant to these modern systems than the MVC pattern.

ASP.NET Web Forms is an event-based system, which is unique with respect to web application platforms. It has a rich control-based, event-driven programming model that developers code against, providing a nice componentized GUI for the Web. When you click a button, a Button control responds and raises an event on the server indicating that it's been clicked. The beauty of this approach is that it allows the developer to work at a higher level of abstraction when writing code.

Digging under the hood a bit, however, reveals that a lot of work is going on to simulate that componentized event-driven experience. At its core, when you click a button, your browser submits a request to the server containing the state of the controls on the page encapsulated in an encoded hidden input. On the server side, in response to this request, ASP.NET has to rebuild the entire control hierarchy and then interpret that request, using the contents of that request to restore the current state of the application for the current user. All this happens because the Web, by its nature, is stateless. With a rich-client Windows GUI app, there's no need to rebuild the entire screen and control hierarchy every time the user clicks a UI widget, because the app doesn't go away.

With the Web, the state of the app for the user essentially vanishes and then is restored with every click. Well, that's an oversimplification, but the user interface, in the form of HTML, is sent to the browser from the server. This raises the question: “Where is the application?” For most web pages, the application is a dance between client and server, each maintaining a tiny bit of state, perhaps a cookie on the client or chunk of memory on the server, all carefully orchestrated to cover up the Tiny Lie. The Lie is that the Internet and HTTP can be programmed against in a stateful manner.

The underpinning of event-driven programming (the concept of state) is lost when programming for the Web, and many are not willing to embrace the Lie of a virtually stateful platform. Given this, the industry has seen the resurgence of the MVC pattern, albeit with a few slight modifications.

One example of such a modification is that in traditional MVC, the model can “observe” the view via an indirect association to the view. This allows the model to change itself based on view events. With MVC for the Web, by the time the view is sent to the browser, the model is generally no longer in memory and does not have the ability to observe events on the view. (Note that you'll see exceptions to this change when this book covers applying Ajax to MVC in Chapter 8.)

With MVC for the Web, the controller is once again at the forefront. Applying this pattern requires that every user input to a web application simply take the form of a request. For example, with ASP.NET MVC, each request is routed (using routing, discussed in Chapter 4) to a method on a controller (called an action). The controller is entirely responsible for interpreting that request, manipulating the model if necessary, and then selecting a view to send back to the user via the response.

With that bit of theory out of the way, let's dig into ASP.NET MVC's specific implementation of controllers. You'll be continuing from the new project you created in Chapter 1. If you skipped over that, you can just create a new MVC 3 application using the Internet Application template and the Razor View Engine, as shown in Figure 1-9 in the previous chapter.