2 Designing the Application

There are several ways to design the sample applications. 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. Yet another way is to use session facade design pattern.

Contents of this chapter:

• Design Goals

• Chaining Pages

• Using Model-View-Controller (MVC)

Note: The session facade design pattern is described in Chapter 10, "Updating EJBs to Use EJB 2.0 Features"

2.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

• Maximize your application performance

2.2 Chaining Pages

In the chaining pages design, pages in an 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 2-1 Chaining Pages

Description of the illustration navchain.gif

Each page can be generated differently. For example, 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 Also: Chapter 5, "Creating Presentation Pages" for a discussion on 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 hard to maintain 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.

2.3 Using Model-View-Controller (MVC)

A better way of designing an 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 way. 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/blueprints/patterns/MVC.html

Which Sample Applications Use MVC

The first and the Web Services client sample applications use MVC. The second application uses the session facade design pattern.

For a description of MVC in the first application, see the chapters in Part II, "The First Sample Application".

For MVC in the Web Services client application, see Chapter 11, "Enabling Web Services in the Application".

2.3.1 MVC Diagram

Figure 2-2 shows a high-level structure of an MVC application. When it 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 2-2 Application Architecture

Description of the illustration mvc.gif

2.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 to a class that handles the request. For example, the first sample application has the following mappings:

Table 2-1 Mappings in the Controller for the First 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. 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 mappings 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.

In the first application, the mappings are hardcoded.

In the Web Services client application (which invokes the operations in the second application through Web Services), the mappings are specified as initialization parameters for the controller servlet. The second application does not use the MVC design pattern.

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 applications, the controller object is a servlet. The pages in the application have links to this servlet.

Using the controller 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.

2.3.3 Model (Business Logic)

The model refers to 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 first 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.

Database Access

Typically, objects in the model read and update data in databases. If you are using Enterprise JavaBeans objects to access the database, you have these options:

• Use entity beans with bean-managed persistence (BMP). For BMP entity beans, you have to write your own code to read and update data in the database.

• Use entity beans with container-managed persistence (CMP). For CMP entity beans, you configure the beans in the deployment descriptors.

BMP entity beans: Consider using DAO (data access object) to separate the database access portion of your application from the BMP entity beans. The BMP entity beans invoke methods in the DAO classes to access the database. 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 first sample application uses BMP entity beans and DAOs. 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/blueprints
http://java.sun.com/blueprints/patterns/catalog.html

CMP entity beans: If you want the EJB container to manage database access for you, you can use CMP entity beans. In the deployment descriptor files, you map the entity beans to tables in the database. The container associates fields in the entity bean with columns in the table.

You can also define container-managed relationships (CMRs) between entity beans in the deployment descriptor files. CMRs enable you to retrieve data for a specific entity bean based on data from another entity bean.

The second sample application uses CMP entity beans and CMRs.

See Also: Chapter 10, "Updating EJBs to Use EJB 2.0 Features"

2.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 applications, 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 applications, all the presentation code is in JSP files. The JSP files call on EJBs and servlets to process requests.