2.3 MVC architecture

To help you understand the role of a portlet and prepare you for effective and well-designed portlet development, a review of the model-view-control (MVC) architecture is necessary. This section will briefly review the MVC Model 2 architecture.

In the simplest of forms, the MVC model 2 architecture is illustrated as in Figure 2-1 on page 56.

Figure 2-1. Simple MVC architecture

2.3.1 Standard MVC architecture

The Model View Control architecture is concerned with separation of responsibilities. The objective, no matter how it is applied or to what type of application, is to segregate a system into components. Each component should be small, identifiable, self-contained and reusable. These components are identified by the role they play in the system. Each role in that system may have several classes working in conjunction to achieve the goal of that role. This section will cover the three roles of MVC: Model, View and Control.

Though the MVC architecture was originally applied to Swing applications, it has gained popularity and widespread acceptance throughout the servlet community. This section is technology-independent, but will use the servlet technology to demonstrate the application of MVC.

Model

This component is responsible for encapsulating all the business logic required by the system. It must be independent of the other components in the system. To achieve this objective, it must be able to retrieve the data required to complete the business rules data by itself or accept very generic receive parameters. Furthermore, it must be able to return the results in a generic form that any potential View component could use. In a typical servlet environment, the Model is represented by one or more Java beans, EJBs or other Java classes.

View

This component is responsible for creating a presentation resource for the results of the Model component. Like all MVC components, the View must be independent of the other components in the system. Its success or failure must not depend on the success or failure of the Model component. In practice, several different View components may be developed in order to create a dynamic, complete and possibly multi-purpose application. In a typical servlet environment, the View is created using Java Server Pages.

Control

At the heart of the MVC architecture is the Controller component. Each client request of the system is routed through the Controller class. Its responsibility is threefold. First, it should evaluate the validity of the request, including the user 's state and any parameter information passed as part of the request. The Controller then decides which Model component has the requisite functionality to satisfy the business requirements of the request. Once the Model component has completed its work, the Controller is responsible for deciding on the appropriate View component to present the results back to the client. If either one of the Model or View components fails, the Controller is responsible for either attempting to satisfy the request in another fashion or deciding on an appropriate View component capable of presenting an error message. In a typical servlet environment, the servlet itself plays the role of the Controller.

2.3.2 Portlet MVC architecture

The MVC architecture can be applied as a design pattern to any system needing to achieve separation of responsibilities. In fact, you will see as you continue through this redbook that the Portal Server itself is architected this way. Furthermore, several of the benefits of the portlet architecture are available to you only if you employ a good MVC design.

Model

The Model in a portlet application is not necessarily different from the Model in any other Java server side application.The Model represents business logic and should not be concerned with the Controller or the View. The Controller could be a servlet, portlet, or a simple Java class. The View could be a JSP or even simple HTML. In theory, then, provided that existing applications employ solid MVC practices, porting the functionality WebSphere Portal should not require any changes to the logic. However, in practice, there are always applications that lack this foresight. The rich API covered later in this chapter will arm you with the tools to tackle this situation. Implementing a rigid commitment to the MVC architecture now will conserve an enormous amount of effort in later migrations or maintenance duties .

View

Like the servlet MVC implementation, the View is traditionally implemented using JSPs or simple HTML. However, because the HTML the View returns will be aggregated, it must not contain page-level tags and must be very mindful of the environment in which it is executing. Furthermore, the Portlet API provides tag libraries which aid in creating dynamic view resources for the portlet environment.

Control

The Controller is responsible for determining the requested mode, executing an appropriate Model and selecting the correct View. The portlet class itself acts as the Controller. Instead of determining the request method as in servlets, portlets need to determine the mode the user has requested . In a normal presentation, where a page is built with several portlets on it, the mode is View. The user, with appropriate permissions, may click the Edit button in order to perform some edit functionality. In this case, the mode is Edit. WebSphere Portal also supports Help and Configure modes.

2.3.3 Portlet MVC sample

In the simplest of portlet applications, the MVC architecture would be applied as in Figure 2-2. Note that Figure 2-2 does not reflect the architecture of the Portal Server, simply the portlets executed by the server in any given single request.

Figure 2-2. Simple Portlet MVC architecture