89An introduction to MVC

In general, three components make up the MVC design pattern:  Model—The data that needs to be displayed

 View—The template that displays the data provided by the model  Controller—Updates the model and selects the appropriate View.

Each of the components in an MVC application is responsible for a single aspect of the overall system that, when combined, can be used to generate a user interface. The ToDo list example considers MVC in terms of a web application, but a request could also be equivalent to the click of a button in a desktop GUI application for example.

In general, the order of events when an application responds to a user interaction or request is as follows:

1 The controller receives the request.

2 Depending on the request, the controller either fetches the requested data from the application model, or it updates the data that makes up the model. 3 The controller selects a view to display and passes the model to it.

4 The view uses the data contained in the model to generate the user interface. When we describe MVC in this format, the controller serves as the entry point for the interaction. The user communicates with the controller to instigate an interac- tion. In web applications, this interaction takes the form of an HTTP request, and when a request to a URL is received, the controller handles it.

Depending on the nature of the request, the controller may take a variety of actions, but the key point’s that the actions are undertaken using the model. The model here contains the business logic for the application, and it’s able to provide requested data or perform actions.

NOTE In this description of MVC, the model is a complex beast, containing all the logic for how to perform an action, as well as any internal state.

For example, consider a request to view a product page for an ecommerce applica- tion. The controller would receive the request, and would know how to contact some product service which is part of the application model. This might fetch the details of the requested product from a database and return them back to the controller.

Alternatively, imagine the controller receives a request to add a product to the user’s shopping cart. The controller would receive the request, and most likely invoke a method on the model to request that the product be added. The model would then update its internal representation of the user’s cart, for example by adding a new row to a database table holding the user’s data.

After the model’s been updated, the controller needs to select a way to display the data. One of the advantages of using the MVC design pattern is that the model repre- senting the data’s decoupled from the final representation of that data, called the view.

This separation creates the possibility for the controller to choose to display the model using a different view, based on where the original request originated, as shown in figure 4.2. If the request came from a standard web application, then the controller can display an HTML view. If the request came from another application, then the controller can choose to display the model in a format the application understands, such as JSON or XML. A request is received from a user 1 Model Request Controller Standard web app Model

In this case, the standard web app is selected, so an HTMLresponse isgenerated.

5

The controller handles the request

2

The controller fetches data from, or updates, the model toperform the requested action

3

The controller selects a view based on the caller that made the

request and passes it the model.

4 HTML Select a View SPA / mobile application JSON Text based UI application Plain text

The selected view usesthe providedmodelto generate an

appropriate response.

5

Figure 4.2 Selecting a different view using MVC depending on the caller. The final representation of the model, created by the view, is independent of the controller and business logic.

The other advantage of the model being independent of the view’s that it improves testability. User interface code’s classically hard to test, as it’s dependent on the environ- ment—anyone who’s written UI tests simulating a user clicking on buttons and typing in forms knows that it’s fragile. By keeping the model independent of the view, you can ensure the model stays easily testable, without any dependencies on UI constructs. As the model often contains your application’s business logic, this is clearly a good thing!

Once the controller has selected a view, it passes the model to it. The view can use the data passed to it to generate an appropriate user interface, for example an HTML web page or a simple JSON object. The view’s only responsible for the generating of the final representation.

This is all there is to the MVC design pattern as applied to web applications. Much of the confusion related to MVC seems to stem from slightly different usages of the term for slightly different frameworks and types of application. In the next section, I’ll show how the ASP.NET Core framework uses the MVC pattern, along with some more

91