4. MVC (Model–View–Controller) Development

A web application often has a 3-tier architecture:

the [DAO] layer handles data access, most often persistent data within a DBMS. But this can also be data coming from sensors, the network, etc.
the [business] 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 [user interface] 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 the [user interface] layer
this request is formatted by the [user interface] layer and transmitted to the [business logic] layer
if the [business logic] 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 reaches the user.

The [business] and [DAO] layers are normally accessed via Java interfaces. Thus, the [business] layer knows only the interface(s) of the [DAO] layer and is unaware of 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 impact on the [business] layer as long as the definition of the [DAO] layer’s interface remains unchanged. The same applies between the [user interface] and [business] layers.

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

Processing a client request follows these steps:

The client sends a request to the controller. The controller handles all client requests. It is the application’s entry point. It is the C in MVC.
The C controller processes this request. To do so, it may need assistance from the business layer. Once the client’s request has been processed, it can trigger various responses. A classic example is:
- an error page if the request could not be processed correctly
- a confirmation page otherwise
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 M model, the M in MVC.
- Step 3 therefore consists of selecting a view (V) and constructing the model (M) required for it.
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 the view. MVC literature is not explicit on this point. If it were the response that were to be called the view, we could call the object that generates this response the view generator.
The view generator V uses the model M prepared by the controller C to initialize the dynamic parts of the response it must send to the client.
The response is sent to the client. Its exact form depends on the view generator. It can be an HTML stream, PDF, Excel, etc.

The MVC web development methodology does not necessarily require external tools. Thus, a Java web application with an 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://.../appli?action=liste).
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, it uses the [business] layer if necessary.
Depending on the result of the execution, the [doAction] method decides which JSP page to display. This is the View (V) in the MVC model.
The JSP page contains dynamic elements that must be provided by the servlet. The [doAction] method will provide these elements. This is the view model, 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 these three contexts.
The [doAction] method renders the view by passing the execution flow to the selected JSP page. To do this, it uses a statement such as [getServletContext() .getRequestDispatcher("JSP page").forward(request, response)].

This MVC design pattern 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, an MVC web application based on servlets and JSP pages will have the following architecture:

For simple applications, this architecture is sufficient. When you’ve written several applications of this type, you realize that the servlets of two different applications:

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

The temptation is then strong to:

factorize 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 an MVC architecture based on servlets and JSP pages.