Core J2ee Design Patterns

Core J2EE Design Patterns

What is a design pattern??? A design pattern is a description of a recurring solution to problem given a context Advantages: •They capture engineering experience •Once described, any level engineer can use the pattern •They allow for reuse •They allow to better define system structure •They provide design vocabulary

Core J2EE Design Patterns

Patterns index

Core J2EE Design Patterns Most widely used patterns

Integration tier Presentation tier: Business tier:  Intercepting  Business Delegate Data Access Object  Session Facade  Service Activator filter  Front controller  Service Locator  Web Service Broke  Composite  Transfer Object  Composite Entity view  View helper  Value List handler  Dispatcher view  Service to worker

Presentation tier

Core J2EE Design Patterns

 Intercepting Filter

Context: The presentation-tier request handling mechanism receives ma fferent types of requests, which require modification, auditing before be rther processed

Problem: Preprocessing and post-processing of a client Web request and esponse are required.

Solution: Create pluggable filters to process common services in a andard manner without requiring changes to core request processing ode. The filters intercept incoming requests and outgoing responses, lowing preprocessing and post-processing. We are able to add and remo ese filters unobtrusively, without requiring changes to our existing code

Presentation tier

Core J2EE Design Patterns

Intercepting Filter

he FilterManager manages lter processing. It creates the ilterChain with the appropriate lters, in the correct order, and nitiates processing.

he FilterChain is an ordered ollection of independent filters.

lter One-Two-Three are the ndividual filters that are mapped to a arget. The FilterChain coordinates their rocessing.

he Target is the resource requested by the client

Presentation tier  Front Controller

Core J2EE Design Patterns

ontext: The presentation-tier request handling mechanism must control d coordinate processing of each user across multiple requests. Such con chanisms may be managed in either a centralized or decentralized man

roblem: The system requires a centralized access point for presentationuest handling. When the user accesses the view directly without going ough a centralized mechanism, two problems may occur: ach view is required to provide its own system services, often resulting in plicate code. ew navigation is left to the views. This may result in commingled view ntent and view navigation

olution: Use a controller as the initial point of contact for handling a requ e controller manages the handling of the request, including invoking sec vices such as authentication and authorization, delegating business cessing, managing the choice of an appropriate view, handling errors, an naging the selection of content creation strategies.

Presentation tier  Front Controller

Core J2EE Design Patterns

Controller is the initial contact point for handling ll requests in the system.

Dispatcher is responsible for view management and navigation, managing the choice of the next view to present to the user, and providing he mechanism for vectoring control to this esource.

A helper is responsible for helping a view or controller complete its processing.

A view represents and displays information to he client. The view retrieves information from a model.

Presentation tier

Core J2EE Design Patterns

 Composite View

Context: Sophisticated Web pages present content from numerous data ources, using multiple subviews that comprise a single display page. dditionally, a variety of individuals with different skill sets contribute to evelopment and maintenance of these Web pages.

Problem: Instead of providing a mechanism to combine modular, atomic portions of a view into a composite whole, pages are built by embedding ormatting code directly within each view

Solution: Use composite views that are composed of multiple atomic bviews. Each component of the template may be included dynamically i e whole and the layout of the page may be managed independently of th ntent.

Presentation tier

Core J2EE Design Patterns

 Composite View

A composite view is a view that is an aggregate of multiple subviews.

he View Manager manages the inclusion of ortions of template fragments into the composite iew.

n included view is a subview that is one atomic ece of a larger whole view. This included view could so potentially be a composite, itself including multiple subviews.

Presentation tier

Core J2EE Design Patterns

 View Helper

Context: The system creates presentation content, which requires rocessing of dynamic business data.

Problem: Presentation tier changes occur often and are difficult to develo nd maintain when business data access logic and presentation formattin gic are interwoven. This makes the system less flexible, less reusable, a enerally less resilient to change.

Solution: A view contains formatting code, delegating its processing sponsibilities to its helper classes, implemented as JavaBeans or custom gs. Helpers also store the view's intermediate data model and serve as usiness data adapters.

Presentation tier

Core J2EE Design Patterns

 View Helper

A view represents and displays information to he client. The information that is used in a dynamic display is retrieved from a model. Helpers support views by encapsulating and adapting a model for use in a display.

helper is responsible for helping a view or controller complete its process us, helpers have numerous responsibilities, including gathering data quired by the view and storing this intermediate model, in which case the lper is sometimes referred to as a value bean.

Presentation tier

Core J2EE Design Patterns

 Dispatcher View

Context: System controls flow of execution and access to presentation rocessing, which is responsible for generating dynamic content.

Problem: The problem is a combination of the problems solved by the Fro ontroller and View Helper patterns in the presentation tier. There is no ntralized component for managing access control, content retrieval or v anagement, and there is duplicate control code scattered throughout va ews.

Solution: Combine a controller and dispatcher with views and helpers to andle client requests and prepare a dynamic presentation as the respons ontrollers do not delegate content retrieval to helpers, because these tivities are deferred to the time of view processing. A dispatcher is sponsible for view management and navigation and can be encapsulate ther within a controller, a view, or a separate component.

Presentation tier

Core J2EE Design Patterns

 Dispatcher View

The controller is typically the initial contact point for handling a request.

dispatcher is responsible for view anagement and navigation, managing e choice of the next view to present the user and providing the mechanism for vectoring control to this reso

view represents and displays information to the client. The information t used in a display is retrieved from a model. Helpers support views by ncapsulating and adapting a model for use in a display.

Presentation tier

Core J2EE Design Patterns

 Composite View

Context: Sophisticated Web pages present content from numerous data ources, using multiple subviews that comprise a single display page. dditionally, a variety of individuals with different skill sets contribute to evelopment and maintenance of these Web pages.

Problem: Instead of providing a mechanism to combine modular, atomic portions of a view into a composite whole, pages are built by embedding ormatting code directly within each view

Solution: Use composite views that are composed of multiple atomic bviews. Each component of the template may be included dynamically i e whole and the layout of the page may be managed independently of th ntent.

Presentation tier

Core J2EE Design Patterns

 Composite View

Context: Sophisticated Web pages present content from numerous data ources, using multiple subviews that comprise a single display page. dditionally, a variety of individuals with different skill sets contribute to evelopment and maintenance of these Web pages.

Problem: Instead of providing a mechanism to combine modular, atomic portions of a view into a composite whole, pages are built by embedding ormatting code directly within each view

Solution: Use composite views that are composed of multiple atomic bviews. Each component of the template may be included dynamically i e whole and the layout of the page may be managed independently of th ntent.

Presentation tier

Core J2EE Design Patterns

 Composite View

Context: Sophisticated Web pages present content from numerous data ources, using multiple subviews that comprise a single display page. dditionally, a variety of individuals with different skill sets contribute to evelopment and maintenance of these Web pages.

Problem: Instead of providing a mechanism to combine modular, atomic portions of a view into a composite whole, pages are built by embedding ormatting code directly within each view

Solution: Use composite views that are composed of multiple atomic bviews. Each component of the template may be included dynamically i e whole and the layout of the page may be managed independently of th ntent.

Presentation tier

Core J2EE Design Patterns

 Composite View

Context: Sophisticated Web pages present content from numerous data ources, using multiple subviews that comprise a single display page. dditionally, a variety of individuals with different skill sets contribute to evelopment and maintenance of these Web pages.

Problem: Instead of providing a mechanism to combine modular, atomic portions of a view into a composite whole, pages are built by embedding ormatting code directly within each view

Solution: Use composite views that are composed of multiple atomic bviews. Each component of the template may be included dynamically i e whole and the layout of the page may be managed independently of th ntent.