J2EE Design Patterns: The Presentation Layer Patterns: Model-View-Controller
In any application, it is the presentation that matters most to the end user. The usability of software depends heavily on the User Interface or Presentation Layer in the case of J2EE. Since it is the Presentation Layer that presents the UI to the user, the solutions for recurring problems have to be standard. That is where Presentation Layer Design Patterns come into the picture.
J2EE Design Patterns: The Presentation Layer Patterns: Model-View-Controller (Page 1 of 4 )
One of the major concerns with the web applications is the separation between the logics that deal with Presentation itself, the data to be presented and the one that controls flow of logic. It is as an answer to such concerns that the Model-View-Controller or MVC pattern was designed. In this discussion I will be concentrating on MVC. The first section will discuss and define MVC. The second section will cover the types of MVC patterns that could be implemented. In the last two sections I will implement both types of patterns within an example. That's the agenda for this discussion.
MVC: What is it?
Though the Model-View-Controller is considered a single Pattern, it consists of three different components. This is due to the nature of the Server-Side Presentation Layer. This layer takes care of not only the UI but also of the state of the application (in other words the data currently displayed as state is represented by the value contained in the attributes of an object). It also handles the processing of user data along with the flow of control. Hence the problem of the Presentation Layer is broken up into three distinct pieces or components: the Model (M), the View (V), and the Controller (C)
Among the three, the Controller sits at the boundary. Hence, it can be considered the one that orchestrates the flow of data between View and Model. Here are the details.
The Model, represented by the character M, stores the application state. To rephrase it, the data extracted from the business logic layer which has to be presented to the user, and after processing passed back to the business logic layer, is contained within the Model. The data can be represented in any form - JavaBeans, files, Network or even memory.
The main task of Model is to provide access to this data. The access is provided as an abstraction of data. To cut a long story short, the Model object represents the Domain data which needs to be used by the Server-Side Presentation Layer.
Typically JavaBeans are used to implement the Model object because JavaBeans easily can represent any type of data store, be it Tables, files etc. For example, if the data to be presented is coming from the Employee table, then the Model implemented with JavaBeans would be a class containing the Columns of the Table as properties of the class. These properties can be access via getters and setters. Each row of the table would be represented by an object of the JavaBeans class. The state of the class would provide data required by the Server-Side Presentation Layer.
The View, represented by V, accesses data from the Model and generates the corresponding User Interface (UI). By itself, the View is stateless i.e. it can't preserve/remember the data for which the UI was generated. Hence it depends on Model for the same.
The main job of the View component is to generate the UI for the data in the format that would be useful for the client. A single Model can have multiple Views. That means different users may require different formats for the same data. For this to be achieved, multiple Views can be registered with the Model. In J2EE, the View is typically implemented using JSP and Custom Tags to format the data. For example, the Employee data may be viewed by the manager according to the work hours per day, while the accountant may want to see the data according to the basic salary of the employees. To provide for this, different Views can be generated using the combination of JSP and custom tags.
As stated earlier, the Controller, the C of MVC, sits at the boundary of the application, intercepting each request. Hence, it can be thought of as the point of first contact for any request. It performs the following tasks:
Coordinating the client requests.
Updating the Model and Views on the basis of user input.
Supervising and planning what needs to be shown and changes to be made.
Calling the chosen Model and executing the embedded logic.
For example, while updating an employee's data, once the data has been updated, which page has to be shown would be decided by the Controller.
To present the components and their jobs pictorially, the diagram would look like this:
From the above diagram it is clear that there is a one-to-many correspondence between the Controller and the View. Inversely the View has a many-to-one correspondence with the Controller. That covers the pieces of MVC. Next let's look at the types of MVC.