3
Application Design

There are several ways to design the architecture of the application described in Chapter 2, "The Sample Application". One way is to "chain" the pages, where page 1 calls page 2, page 2 calls page3, and so on. Another way is to use the model-view-controller (MVC) design pattern.

Contents of this chapter:

• Section 3.1, "Design Goals"

• Section 3.2, "Chaining Pages"

• Section 3.3, "Using Model-View-Controller (MVC)"

3.1 Design Goals

You want to design your application such that changes to one part of the application has minimal or no impact on other parts. This enables you to:

• Add features without redesigning your application

• Add new client types (such as wireless devices)

• Change client interfaces with minimal impact to your business logic

• Change business logic without changing presentation data

• Change your database schema or data source with minimal impact on your application

3.2 Chaining Pages

In the chaining pages design, pages in the application are linked sequentially. Page 1 has a link that calls page 2, page 2 has a link that calls page 3, and so on. Graphically:

Figure 3-1 Chaining pages

Text description of the illustration da_desia.gif

Each page can be generated differently. For example, the page 1 can be a plain HTML file, page 2 can be generated by a servlet, while page 3 can be generated by a JSP. The pages contain links or form elements (if the user needs to enter some values) to enable the user to get to the next page. In any case, the link to the next page is hardcoded on each page. See Chapter 5, "Creating Presentation Pages" for a discussion of generating HTML or other markup language.

Advantages of this design are that it is straightforward and easy to understand. This design is manageable for small applications that are unlikely to get bigger or whose pages are unlikely to change.

Disadvantages of this design are that there is no central point to handle client requests and it is difficult to move pages around. If pages get moved, added, or removed from the application, the application becomes less organized because you have to track down the code that one page calls and move it to another page, or change dependencies so that a page can be called from a different page.

3.3 Using Model-View-Controller (MVC)

A better way of designing this application is to use the MVC (model-view-controller) design pattern. MVC enables the application to be extensible and modular by separating the application into three parts:

• the business logic part, which implements data retrieval and manipulation

• the user interface part, which is what the application users see

• the controller part, which routes requests to the proper objects.

By separating an application into these parts, the MVC design pattern enables you to modify one part of the application without disturbing the other parts. This means that you can have multiple developers working on different parts of the application at the same time without getting into each other's domain. Each developer knows the role that each part plays in the application. For example, the user interface part cannot contain any code that has to do with business logic, and vice versa.

MVC also makes it easy to transform the application into a portlet or to have wireless devices access the application.

For more details on MVC, see:

http://java.sun.com/j2ee/blueprints/design_patterns/model_view_controller/index.html

3.3.1 MVC Diagram

The following figure shows a high-level structure of the sample application. When the application receives a request from a client, it processes the request in the following manner:

1. The client sends a request, which is handled by the controller.

2. The controller determines the action specified by the request, and looks up the class for the action. The class must be a subclass of the AbstractActionHandler class.

3. The controller creates an instance of the class and invokes a method on that instance.

4. The instance processes the request. Typically, it forwards the request to a JSP page.

5. The JSP page gets an instance of the Enterprise JavaBean appropriate for the action and invokes the method to perform the action.

6. The JSP page then extracts the data that the method returned for presentation.

   Figure 3-2 Application architecture

   

   Text description of the illustration da_desi2.gif

3.3.2 Controller

The controller is the first object in the application that receives requests from clients. All requests for any page in the application must first go through the controller.

In the controller, you map each request type with a class to handle the request. For example, the sample application has the following mappings:

Table 3-1 Mappings in the controller for the sample application

Action	Class
queryEmployee	empbft.mvc.handler.QueryEmployee
addBenefitToEmployee	empbft.mvc.handler.AddBenefitToEmployee
removeBenefitFromEmployee	empbft.mvc.handler.RemoveBenefitFromEmployee

The action is a query string parameter passed to the controller. The controller gets the value of the action parameter to determine the type.

When the controller receives a request, it looks up the value of the action parameter, determines the class for the request, creates an instance of the class, and sends the request to that instance.

You can hardcode the mapping in the controller code itself, or you can set up the controller to read the mapping information from a database or XML file. It is more flexible to use a database or XML file.

By having a controller as the first point of contact in your application, you can add functionality to your application easily. You just need to add a mapping and write the new classes to implement the new functionality.

In the sample application, the controller object is a servlet. The pages in the application have links to this servlet.

Using the controller object frees you from "chaining" pages in your application, where you have to keep track of which page calls which other pages, and adding or removing pages can be a non-trivial task.

3.3.3 Model (Business Logic)

The model represents the objects that implement your business logic. The objects process client data and return a response. The model also includes data from the database. Objects in the model can include Enterprise JavaBeans, JavaBeans, and regular Java classes. Views and controllers invoke objects in the model.

After the controller has read the request, objects in the model perform all the actual work in processing the request. For example, the objects can extract values from the query string and validate the request, authenticate the client, begin a transaction, and query databases. In the sample application, the EmployeeManager session bean calls the Employee entity bean to query the database and get information for an employee.

Although it is tempting to encode presentation data in your business logic, it is a better practice to separate the presentation data into its own file. For example, if you write the presentation data in a JSP file, you can edit the HTML markup in the file or change the format of the data without changing the model code. The page can then format the data accordingly. JSP files do not care how the methods get their data.

Typically, objects in the model read and update data in databases. If your application accesses databases, consider using DAO (data access objects) to separate the database access portion of your application from the rest of the model. This enables you to isolate the SQL statements that you send to the database.

Using DAOs gives you the flexibility to change your data source. If you update your database (for example, if you rename tables in the database or change the structure of tables in the database), you can update your SQL statements in the data access objects without changing the rest of your application.

The sample application uses a DAO to connect to the database. The DAO sets up a connection to the database, executes the required SQL statements on the database, and returns the data.

For additional information on how to create a "clean" model, you might want to read the J2EE blueprints page and the Design Patterns Catalog page on the Sun site:

http://java.sun.com/j2ee/blueprints
http://java.sun.com/j2ee/blueprints/design_patterns/catalog.html

3.3.4 View

The view includes presentation data such as HTML tags along with business data returned by the model. The presentation data and the business data are sent to the client in response to a request. The HTML tags usually have data and form elements (such as text fields and buttons) that the user can interact with, as well as other presentation elements.

The presentation data and the business data should come from different sources. The business data should come from the model, and the presentation data should come from JSP files. This way, you have a separation between presentation and business data.

One benefit of coding the business and presentation data separately is that it makes it easy to extend the application to support different client types. For example, you might need to extend your application to support wireless devices. Wireless devices read WML or other markup language, depending on the device. If you embed your presentation data in your business logic, it would be difficult to track which tag is for which client type. With the separation, you can reuse the same business objects with new presentation data.

In addition, new clients of the application might not even be graphical at all. They might not be interested in getting display tags. They might only be interested in getting a result, which they can process however they like.

The files for the presentation data should not contain any business logic code, other than invoking objects on the model side of the application. This enables you to change the implementation of the business logic and database schema without modifying the client code.

In the sample application, client types include browsers, different types of wireless devices, non-web clients (such as other applications), and SOAP clients. You can add clients or change how the data is presented to the clients just by changing the "view." The data can be HTML, WML, or any other markup language.

In the sample application, all the presentation code is in JSP files. The JSP files call on EJBs and servlets to process requests.