Java EE Patterns

Dan Bugariu

What is Java EE ?

What is a Pattern ?

Historical References

1970 Christopher Alexander A Pattern Language

1994 GoF Design Patterns: Elements of Reusable Object-Oriented Software

2003 Alur, Crupi, Malks Core J2EE Patterns

Software Pattern types

design patterns architectural patterns analysis patterns creational patterns structural patterns behavioral patterns

Java EE Patterns categories

presentation tier patterns business tier patterns integration tier patterns

Intercepting Filter

Context Problem Solution Consequences

Centralizes Control with Loosely Coupled Handlers

Improves Reusability Declarative and Flexible Configuration Information Sharing is Inefficient

Front Controller

Context Problem Solution Consequences

Centralizes Control Improves Manageability of Security Improves Reusability

Application Controller

Context Problem Solution Consequences

Improves modularity Improves reusability Improves extensibility

Business Delegate

Context Problem Solution Consequences

Reduces coupling, improves maintainability Translates business service exceptions Improves availability Exposes a simpler, uniform interface to the business tier Improves performance Introduces an additional layer Hides remoteness

Service Locator

Context Problem Solution Consequences

Abstracts complexity Provides uniform service access to clients Facilitates adding EJB business components Improves network performance Improves client performance by caching

Session Façade

Context Problem Solution Consequences

Introduces a layer that provides services to remote clients Exposes a uniform coarse-grained interface Reduces coupling between the tiers Promotes layering, increases flexibility and maintainability Reduces complexity Improves performance, reduces fine-grained remote methods Centralizes security management Centralizes transaction control Exposes fewer remote interfaces to clients

Application Service

Context Problem Solution Consequences

Centralizes reusable business and workflow logic Improves reusability of business logic Avoids duplication of code Simplifies facade implementations Introduces additional layer in the business tier

Data Model Object

Context Problem Solution Consequences

Promotes object-oriented approach to the business model implementation

Separates persistence logic from data model and business logic

Transfer Object

Context Problem Solution Consequences

Reduces network traffic Simplifies remote object and remote interface Transfers more data in fewer remote calls Reduces code duplication Increases complexity due to synchronization and version

control

Domain Store

Context Problem Solution Consequences

Creating a custom persistence framework is a complex task Multi-layer object tree loading and storing requires

optimization techniques Improves understanding of persistence frameworks Improves testability of your persistent object model Separates business object model from persistence logic

Q&A

Gata