Programming Microsoft ASP.NET 4 - Dino Esposito [317]
Note
The impact of frameworks and technologies on the presentation layer is a huge point to consider. Originally, the MVP pattern had been proposed as a way to improve MVC. So does this mean that ASP.NET MVC is a thing of the past? Of course, not. There are probably ways to further improve the design of ASP.NET MVC applications, but the ASP.NET MVC framework is highly usable and guides you toward writing well-designed code without the cost of arranging everything yourself.
The MVC Pattern
In the earliest software, the whole application was made of monolithic blocks that encompassed everything—the user interface, logic, and data. The user interacted with the view and generated some input. The view captured the input, processed it internally, and updated itself or moved to another view. The MVC pattern was introduced in the late 1970s as a way to break such monoliths (called autonomous views) into distinct pieces.
Generalities of the MVC Pattern
According to the MVC pattern, the application is split into three distinct pieces: the model, the view, and the controller. The model refers to the data being worked on in the view. The model is represented with an active object that is updated by the controller and notifies the view of its state changes. The view refers to the generation of any graphical elements displayed to the user, and it captures and handles any user gestures. The controller responds to solicitations and executes actions against the application’s back end. Such actions produce fresh data that alter the model. The controller is also responsible for selecting the next view. Figure 15-1 provides a graphical representation of the MVC schema.
Figure 15-1. The Model-View-Controller pattern.
The major benefit of MVC is the application of the separation of concerns (SoC) principle. It mostly consists of taking as much code as possible out of the front end to build structured layers. As mentioned earlier, in the beginning, MVC was just a way to break up monolithic programs in which the code basically consists of a loop around some input and each command is resolved through a logical transaction. (See the Transaction Script pattern in Chapter 14.)
Let’s see what it takes to use the MVC pattern to build Web Forms applications.
Role of the Model
According to the definition, the model in MVC is the representation of the data as the view is expected to consume it. The model is where the view copies any data posted by requests and where it gets any data to be incorporated in the response. You should have a different model (say, a class) for each view. The model should have properties for each significant piece of data the view handles.
The problem here is that in Web Forms the model is often bypassed because views are made of server controls and server controls expose input data and receive response data.
Role of the View
In Web Forms, the view coincides with a page. The page is made of server controls, and server controls provide input elements for the user to interact with. The view is responsible for producing the collection of visual elements displayed to users—the ASPX markup—as well as for processing user gestures—the code-behind class. In an MVC scenario, there should be some sort of event-based dependency between the view and model. When the model is updated, the view should be notified, grab up-to-date information, and refresh.
The code in the view should be as simple as possible, ideally limited to just dispatching calls to another layer—the controller.
Role of the Controller
The controller is the place where the action that the user requested is actually performed. The action might require the controller to select a new view which, in Web Forms, would be a redirect. More likely, the action will lead the controller to interact with the middle tier to obtain a response. The response obtained will then be massaged in some way and placed