|[ Team LiB ]|
The Model 1 and Model 2 Architectures
When JSPs were first introduced, the specifications distinguished the uses of JSPs from servlets by defining two model architectures. Recent specifications have dropped the topic, leaving it (more appropriately) to the J2EE blueprint to define. The models are still useful, so we'll take a few minutes to review them.
The Parts of the J2EE Standard
In the Model 1 architecture, JSPs accept client requests, decide which actions to take next, and present the results. JSPs work with JavaBeans or other services to affect business objects and generate the content. The important thing to remember about this model is that a JSP always remains in control of the application. Figure 20.1 illustrates a Model 1 architecture.
Unfortunately, this almost always means that the JSP has a considerable amount of business logic in it, usually in the form of scriptlets littered throughout the page. In most implementations, it's a complex document that rarely meets the objectives presented earlier this hour.
Consider Your Architectural Requirements
In the Model 2 architecture, a servlet accepts a client request, handles the processing, and then forwards to a JSP for presentation. In this architecture, the servlet can access the business objects, obtain the information that needs to be displayed, and pass it along to a JSP that is dedicated to presentation. It's quite easy to keep the business logic in the servlet (and Java code for that matter) and use JSPs strictly for presentation. The view of the information will be constructed using directives and standard and custom actions. For the really tough presentation problems, EL is there to help. Figure 20.2 depicts the Model 2 architecture.
Using the Model 2 architecture helps partition functionality and results in reduced coupling between components, making the application flexible and easier to maintain. Let's look at a successful Model 2 architecture in more detail.
|[ Team LiB ]|