The MVC pattern has been around for a long time—decades before this era of modern web applications. When MVC fi rst 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 Chapter 3 covers in more detail).
In the late 1970s and early 1980s, researchers at Xerox PARC (which, coinciden- tally, 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 fi red 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 handled 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 a button is clicked, a button control responds and raises an event on the server indicating that it has 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 a button is clicked, the 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 cur- rent 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, no need exists to rebuild the entire screen and control hierarchy every time the user clicks a UI wid- get, because the application 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 oversimplifi cation, but the user interface, in the form of HTML, is sent to the browser from the server. This raises the ques- tion: “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 again 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 virtu- ally stateful platform. Given this, the industry has seen the resurgence of the MVC pattern, albeit with a few slight modifi cations.
One example of such a modifi cation 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 exceptions to this change exist, as described in Chapter 8, regarding the application of Ajax to MVC.)
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 9) to a method on a controller (called an action). The control- ler 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.
From Ebook : Profesional asp.net MVC 5