General Design Recommendations

When designing the presentation tier in a multi-tier architecture, the following recommendations should be considered:

• Analyze the user needs and plan for supporting appropriate client access options for the application. For example, Canaxia's retail application for scheduling delivery that is used by the back-office personnel may not require access via a mobile device. On the other hand, it is useful to have an application for notification on a cell phone when the automobile is ready for delivery or one that provides customers with the ability to query using SMS (Short Message Service) in Asia and the WAP (Wireless Access Protocol) browser in Europe to find the state of readiness of the automobile from a Canaxia service station.

• Identify the kinds of user interface components you will need, keeping in mind the client access paradigms that need to be supported. For example, if both Web site and cell phone access need to be provided, a separate UI control or component needs to be mapped for each target platform based upon device capabilities.

• Determine the scope of internationalization and co-branding early. The static text and the look and feel of the UI may need to change to support such features. In most cases, keeping the content and the display attributes separate in the individual UI components may be sufficient. Either as a part of the build process or at run-time, the content and display attributes can be packaged together in the UI to create the desired internationalized and co-branded applications.

• Appropriate controllers must be chosen as part of the target platform selection. In a Web-based application, a one-screen-long input form may be sufficient to capture the requisite information and one submit button may be necessary to post the information back to the application. However, in a smaller WAP-enabled device, it may be necessary to split the form into several screen-long forms, the submit trigger may post smaller chunks of data, and the final submit may post all the data to the application, making the device specificity transparent to the application.

• Keep code that enforces policies (such as security, operational management, and communication restrictions) abstracted as much as possible from the application business logic. Try to rely on attributes, APIs, or utility components that provide single-line-of-code access to functionality related to the policies, such as publishing exceptions, authorizing users, and so on.

• Determine at the outset what kind of layering (tiers) you want to enforce. In a strict layering system, components in the presentation tier cannot call components in the data tiers; they always call components in the business logic tiers. In some cases, it may be appropriate for the presentation tier to call the data tiers directly so that the change in the model can immediately reflect on the UI. This reduces the intermediate layer that only acts as a pass-through layer. Monitoring-type applications are typically good candidates when relaxed layering may be appropriate.

Designing the Presentation Tier

The presentation layer contains the components required to enable user interaction with the application. The most simple presentation layers contain user interface components, such as SWING for JAVA clients. For more complex user interactions, you can design user process components to control the different user interface elements and the user interaction. User process components are especially useful when the user interaction follows a predictable flow of steps, such as when a wizard is used to accomplish a task.

In the case of the Canaxia retail application, several user interfaces are required: one for the e-commerce Web site that the customers use, another for the fat-client based applications that the sales representatives use, another that is document based (such as Microsoft Excel) that the retail clerk uses to update bulk orders, and yet that is cell-phone based to buy the merchandise. Figure 9-3 illustrates the use of multiple client access to the same application.

Figure 9-3. The Canaxia retail application.

All users may perform some common tasks through these user interfaces. For example, they may view the available product details, add products to an order, and specify payment details as part of the purchase process. This process can be abstracted in a separate user process component to make the application easier to maintain. In this section, we explore each of the client environments and understand the design considerations behind each. We also explore how the presentation tier needs to provide the architectural framework for providing access to different clients without affecting the underlying application.

Designing User Interface Components

You can implement user interfaces in many ways. As illustrated in Figure 9-3, the Canaxia retail application example requires a Web-based user interface, a fat-client based user interface, a document-based interface, and a cell-phone based interface. Other kinds of user interfaces, such as voice rendering, can possibly be included in the mix. User interface components manage interaction with the user. They display data to the user, acquire data from the user, and interpret events that the user raises to act on business data, to change the state of the user interface, or to help with progress in the desired task.

User interfaces usually consist of a number of screen elements or a form that displays data and accepts user input. For example, a fat-client based application could contain a data-grid control displaying a list of product categories and a command button control to indicate that the user wants to view the products in the selected category. When a user interacts with a user interface element, an event is raised that calls code in a controller function. The controller function, in turn, calls business components, data access logic components, or user process components to implement the desired action and retrieve any necessary data to be displayed. The controller function then updates the user interface elements appropriately.

The user interface screen elements may map themselves to different and yet similar controls that are appropriate for different target platform or technologies. For example, the order list may be displayed in a data table in the Web application, as a data grid in the fat-client, as a spreadsheet in the document client, and as a bulleted list in the cell phone. Figure 9-4 shows the design of a user interface.

Figure 9-4. User interface design.