33
Object-Oriented Enterprise Application Development J2EE Blueprints

Object-Oriented Enterprise Application Development J2EE Blueprints

  • View
    219

  • Download
    2

Embed Size (px)

Citation preview

Object-Oriented Enterprise Application Development

J2EE Blueprints

Topics

During this class we will examine:

J2EE Blueprints and patterns featuring servlets and JavaServer Pages.

J2EE Blueprints & Patterns

Patterns

The J2EE patterns have two (2) primary goals:

Reduce coupling and dependencies between components.

Minimize network traffic.

These patterns are a work in progress and continue to evolve.

Patterns & Tiers

The patterns have been separated by tier:Presentation

Business

Integration

We'll focus on the presentation and integration tiers.

Patterns

We'll look at the following integration tier patterns:

Data Access Object

We'll look at the following presentation tier patterns:

FrontController

ViewHelper

CompositeView

Data Access Object

Problem

Applications require persistence.

Access mechanisms and APIs vary across different persistence technology.

Components should be independent of the actual persistence mechanism.

One Solution

Use the DAO pattern to isolate persistence semantics from business semantics.Business components use the DAO to access the persistence layer.This pattern could be merged with the Strategy, Builder, and Abstract Factory patterns to allow for the dynamic selection of persistence mechanisms.

Participants

Business Object: Requires access to the Data Store.

Data Access Object: Translates requests from the Business Object into requests against the Data Store.

Data Store: Performs actual storage of the data.

Sequence

Results

Data access is transparent since the client code doesn't need to know the implementation details.

Centralizes all data access into its own layer thus providing better application partitioning reduced client complexity.

Front Controller

Problem

There are common processes required by all requests made to an application.

SecurityContent retrieval

There is no centralized handler for these requests.This makes each component perform these tasks in its own way which can lead to redundant code.

One Solution

Use the Front Controller pattern to provide a single point of contact for all client requests.The Front Controller integrates with all other application services such as security, persistence, etc.This allows common code to be moved into the Front Controller.

Participants

Front Controller: The initial point of contact for all client requests.

Sequence

Results

Provides centralized control since all requests funnel through the Front Controller.As common services are moved into the Front Controller, we gain improved manageability.Common services can be performed in a consistent way.

View Helper

Problem

To effectively create dynamic content, we often need to mix business and presentation logic.

Such a combination can result in an application that is difficult to maintain.

Such a combination doesn't promote the separation of roles within a project.

One Solution

Requests are forwarded to a logical view.

Business logic is removed from the view and factored into helper classes such as JavaBeans.

Participants

View: The logical view that is ultimately responsible for generating the content presented to the client.

ViewHelper: An object that encapsulates various business logic that is called on by the view to construct the dynamic content.

Sequence

Results

Improved role separation and application partitioning by factoring business logic from presentation logic.

Since the business logic is encapsulated into a helper object that can be used elsewhere in an application, we can achieve improved reuse.

Composite View

Problem

Certain elements of a web-based application may be common to multiple views.

If these elements are coded directly into each view, we may have maintenance and consistency issues in the future.

One Solution

Use a Composite View to assemble various atomic components into the final view.

Each atomic element can be re-used in other views.

Participants

Composite View: The view ultimately responsible for presenting content to the client.

View Manager: An object that knows how to assemble the final elements into the view.

Sequence

Results

Separate maintenance of common elements from the view in which they're used.

May improve manageability because of the dynamic nature of the view inclusion mechanism.

Review

During this class we have discussed:

J2EE Blueprints and patterns featuring servlets and JavaServer Pages.

Resources

JDBC Database Access with JavaGraham Hamilton, Rick Cattell, Maydene Fisher, Addison-Wesley, 1997.ISBN: 0-201-30995-5

Coming Attractions

Next week we'll have the presentations.