MVC and The Web

Posted September 4, 2008 by kanian77
Categories: MVC and the web

Tags:

MVC was originally applied in a desktop application environment where the application resides on the computer with wich the user is interacting.

While interacting with a web application, the user is sending requests to a distant server through his browser (the client). The server possess the necessary ressources to respond to the user’s request. The user receives the server’s response on its browser window. Thus when developers wan to apply the MVC pattern to a web application, they have to take into consideration the client/server environment in which the application operates.

We will cite Lech MADEYSKI, Michał STOCHMIAŁEK1 :

  • The HTTP protocol, the technological foundation of web applications, is stateless.
  • Each command is executed independently, without any knowledge of the commands that
    came before it.
  • Web application’s responsibility is to keep the state between requests.
  • Conversation between user and application can be initiated only by the user.
  • Control flow of web applications is driven by user requests. It usually consists of
    complex sequence of interactions between the user and server.

A typical MVC application can be represented by this diagram2

There exist different solutions to using MVC in a web application. For example server side MVC or MVC/Model 2 will host the Controller, the View and the Model on the server.

Server side MVC or MVC/Model 2

The simplest way to use MVC in a web application is to put the Controller , the View and the Model on the server. The user request will be transmitted by the web client as a request to the server that will pass it to the controller. The controller will interpret the user request as a command to the model ( CRUD operations). The controller will make the result of the operation available to the view. The view can then send a response to the web client for display. Here the client will be considered We can represent the process by the following diagram3

This approach to adapte MVC to a web environment was termed the MVC/Model 2 design pattern.

On the Apache Struts website 4 we can read:

In the MVC/Model 2 design pattern, application flow is mediated by a central Controller. The Controller delegates requests – in our case, HTTP requests – to an appropriate handler. The handlers are tied to a Model, and each handler acts as an adapter between the request and the Model. The Model represents, or encapsulates, an application’s business logic or state. Control is usually then forwarded back through the Controller to the appropriate View. The forwarding can be determined by consulting a set of mappings, usually loaded from a database or configuration file.5

In fact with this pattern there are two communication cycles between the different components of the MVC triad that may arise:

  • The « User → Controller → View → User » cycle in which the User interaction with the application is sent to the Controller as HTTP request. The Controller chooses the View to show to the User based on the request parameters.Finally it updates the View and returns it as a response to the User.

  • The « User → Controller → Model → View → User » cycle in which the User interaction with the application is sent to the Controller as HTTP request. The Controller access the Model and updates it. It chooses the View to show to the User based on the request parameters.Finally it updates the View to reflect the Model change and returns it as a response to the User.

Mixed client-side and server-side MVC

The client processing power is used to carry on user data validation or view change that do not require accessing the server side Controller and/or Model.6

With this solution there are three communication cycles between the different components of the apllication:

  • The « User Controller (Client) View (Client) User » cycle:

In this case the user action is intercepted by the client-side Controller which decides that only the client-side View( the UI) is affected by the User’s action. The client-side Controller will update the client-side View that will make the modifications visible to the User.

  • The « User → Controller (Client) → Controller(Server) →View (Server) → View (Client)→User » cycle:

Here the User action is intercepted by the client-side Controller which decides to send them as HTTP request to the server-side Controller. The server-side Controller will update the server-side View and send it to the client-side View. For example, this communication cycle can be used when a User wants to change the application presentation (layout).

  • The « User → Controller (Client) → Controller(Server) → Model → View (Server) → View(Client) → User » cycle:

Is similar to the precedent. The difference here is that the server-side controller decides that the Model should be updated and updates the server-side View that will be sent to the client-side View and finally displayed to the User.7

Mixed client-side and server-side MVC (2)8

With this approach the client-side Model contains a copy of the data the user wants to access. It is the client-side Model responsability to communicate with the server-side Controller when the server-side Model needs to be updated or accessed.

Mixed client-side and server-side MVC (3)

One can imagine and develop web applications where only part the M of the MVC lives on the server. Morales-Chaparo et al call this approach RIA MVC. This allows for part of the less critical operations involving the model to happen at the client. A request is sent to server only when the client-side Model needs access to the server-side Model.

——-

Note:

I believe that more and more web applications developpers will chose this “almost all client-side web MVC pattern”. Already, some javascript frameworks are openly claiming adhering to the MVC pattern (javascriptMVC).

——-


1 ARCHITECTURAL DESIGN OF MODERN WEB APPLICATIONS, Lech MADEYSKI, Michał STOCHMIAŁEK, Wroclaw University of Technology, Poland.


2 Web MVC, http://osteele.com/archives/2004/08/web-mvc ,Oliver Steele, 2004

3 Understanding JavaServer Pages Model 2 architecture, Exploring the MVC design pattern, Govind Seshadri, JavaWorld.com, 12/29/99

4 Apache Struts, http://struts.apache.org/, is a framework for creating enterprise-ready Java web applications

5 http://struts.apache.org/primer.html#mvc

6MVC Web design patterns and Rich Internet Applications, Morales-Chaparro, R.; Linaje, M.; Preciado, J. C.; Sánchez-Figueroa F. QUERCUS Software Engineering Group, Escuela Politécnica. Universidad de Extremadura

7 ibid

8 ibid

The Benefits and Drawbacks of using The MVC Pattern

Posted September 3, 2008 by kanian77
Categories: MVC and the web

IV The Benefits of using The MVC Pattern1

  • Different views and controllers can be substituted to provide alternate user interfaces for the same model.
  • Multiple simultaneous views of the same model
  • The change propagation mechanism insures that all views simultaneously reflect the current state of the model.
  • Changes affecting just the user interface of the application become easier to make.
  • With MVC it can be easier to test the core of the application, as encapsulated by the model.

V The problems of MVC2

  • There’s increased complexity as an apllication may use other patterns at the same time as MVC.
  • The view and the controller are closely coupled wich makes modification to one affect the other.
  • Changes to the model interface will necessitate changes to the controller and the view.
  • When the model is active frequent changes to model can result in excessive updates of the corresponding views.

1

Model View Controller explication page of the phpWACT framework, http://www.phpwact.org/pattern/model_view_controller

2ibid