4. MVC Development (Model–View–Controller)

A web application often has a three-tier architecture:

• the [dao] layer handles data access, most often persistent data within a SGBD. But this can also be data coming from sensors, the network, etc.
• The [metier] layer implements the application’s “business” algorithms. This layer is independent of any form of user interface. Thus, it must be usable with a console interface, a web interface, or a rich client interface. It must therefore be testable outside the web interface, particularly with a console interface. This is generally the most stable layer of the architecture. It does not change if the user interface or the method of accessing the data necessary for the application’s operation is altered.
• The [interface utilisateur] layer, which is the interface (often graphical) that allows the user to control the application and receive information from it.

Communication flows from left to right:

• the user makes a request to layer [interface utilisateur]
• this request is formatted by the [interface utilisateur] layer and transmitted to the [métier] layer
• if the [métier] layer needs data to process this request, it requests it from the [dao] layer
• Each queried layer returns its response to the layer to its left until the final response is sent to the user.

The [métier] and [dao] layers are normally used via Java interfaces. Thus, the [métier] layer knows only the interface(s) of the [dao] layer and does not know the classes implementing them. This is what ensures the independence of the layers from one another: changing the implementation of the [dao] layer has no effect on the [métier] layer as long as the definition of the [dao] layer’s interface remains unchanged. The same applies to the [interface utilisateur] and [métier] layers.

The MVC architecture (Model–View–Controller) is implemented in the [interface utilisateur] layer when it is a web interface:

The processing of a client request follows these steps:

1. The client sends a request to the controller. The controller handles all requests from clients. This is the application’s entry point. It is the C in MVC.
2. Controller C processes this request. To do so, it may need assistance from the business layer. Once the client’s request has been processed, it may trigger various responses. A classic example is:
   • an error page if the request could not be processed correctly
   • a confirmation page otherwise
3. the controller chooses the response (= view) to send to the client. Choosing the response to send to the client involves several steps:
   • selecting the object that will generate the response. This is called the view V, the V in MVC. This choice generally depends on the result of executing the action requested by the user.
   • Providing it with the data it needs to generate this response. Indeed, this response most often contains information calculated by the controller. This information forms what is called the view’s model M, the M in MVC.
   • Step 3 therefore consists of selecting a view V and constructing the model M required for it.
4. The controller C instructs the selected view to display itself. This usually involves executing a specific method of the view V responsible for generating the response to the client. In this document, we will refer to both the object that generates the response to the client and the response itself as a view. The MVC documentation is not explicit on this point. If the response were to be called a view, we could call the object that generates this response a view generator.
5. The view generator V uses the template M prepared by the controller C to initialize the dynamic parts of the response it must send to the client.
6. The response is sent to the client. Its exact form depends on the view generator. It can be a HTML stream, PDF, Excel, ...

The MVC web development methodology does not necessarily require external tools. Thus, a Java web application with a MVC architecture can be developed using a simple JDK and basic web development libraries. A method suitable for simple applications is as follows:

• The controller is handled by a single servlet. This is the C in MVC.
• All client requests contain an action attribute, for example (http://.../app?action=list).
• Depending on the value of the action attribute, the servlet executes an internal method of type [doAction(...)].
• The [doAction] method executes the action requested by the user. To do this, if necessary, it uses the [métier] layer.
• Based on the result of the execution, the method [doAction] determines which JSP page to display. This is view V of the MVC model.
• The page JSP has dynamic elements that must be provided by the servlet. The method [doAction] will provide these elements. This is the model of the view, the M in MVC. This model is most often placed in the request context (request.setAttribute("key", "value"), or less frequently, in the session or application context. A JSP page has access to all three contexts.
• The [doAction] method displays the view by passing the execution flow to the selected JSP page. To do this, it uses a statement of the form [getServletContext() .getRequestDispatcher(" pageJSP ").forward(request, response)] .

This design pattern, MVC, is called the "Front Controller" pattern or single-controller pattern. A single servlet handles all requests from all users.

Let’s return to the architecture of the previous web application:

This architecture corresponds to the following n-tier architecture:

There is actually only one layer: the web interface layer. Generally speaking, a web application MVC based on servlets and pages JSP will have the following architecture:

For simple applications, this architecture is sufficient. Once you’ve written several applications of this type, you’ll notice that the servlets in two different applications:

1. use the same mechanism to determine which [doAction] method to execute to handle the action requested by the user
2. in fact differ only in the content of these [doAction] methods

The temptation is then strong to:

• factor out the processing (1) into a generic servlet that is unaware of the application using it
• delegate the processing (2) to external classes since the generic servlet does not know in which application it is being used
• link the action requested by the user to the class that must process it using a configuration file

Tools, often called "frameworks," have emerged to provide developers with these capabilities. The oldest and probably best-known of these is Struts (http://struts.apache.org/). Jakarta Struts is a project of the Apache Software Foundation (www.apache.org). This framework is described in (http://tahe.developpez.com/java/struts/).

The Spring framework (http://www.springframework.org/), which appeared more recently, offers features similar to those of Struts. Its use has been described in several articles (http://tahe.developpez.com/java/springmvc-part1/).

We now present an example of a MVC architecture based on servlets and JSP pages.