Mastering EJB Design Patterns: Boost Performance and Maintainability

Importance of Design Patterns

In J2EE projects that use EJB technology, the quality of the architecture directly affects system performance, scalability, maintainability, component reusability, and development efficiency. The larger and more complex the project, the more critical good design becomes.

Common EJB Design Patterns

Session Facade Pattern

Clients often need to perform many operations on server‑side data. Directly exposing entity EJBs to clients leads to high network load, low concurrency performance, tight coupling, poor reusability, and maintenance difficulties. Introducing a Session EJB layer isolates business logic, reduces network traffic, and improves performance.

Avoid creating an overly large Session EJB that handles all operations.

Keep database access in entity EJBs, not in the Session layer.

Encapsulate common services (e.g., permission checks) in separate Java classes.

Message Facade Pattern

When a request must invoke multiple EJBs without needing an immediate response, the Message Facade (based on Message‑Driven Beans) handles asynchronous calls, solving long client wait times and low fault tolerance of the Session Facade.

Drawbacks: no return value, exceptions cannot be sent back directly, and message content validation depends on the client.

EJB Command Pattern

Session Facade can cause frequent code changes, heavy client‑side API usage, and costly redeployments. The Command Pattern moves business logic into lightweight Java classes (Command Beans) and separates routing logic from execution.

Structure includes Command Bean, client‑side routing logic, and remote command server (often a Session EJB).

Benefits: faster development, clear separation of presentation and business layers, easier client debugging.

Weaknesses: less transaction control, statelessness, no direct exception propagation, and potential proliferation of Command Beans in large projects.

Data Transfer Object (DTO) Factory

Transferring large amounts of data between client and server is common in EJB‑based J2EE applications. A DTO Factory encapsulates DTO creation and management, decoupling DTOs from entity EJBs and improving reusability.

Implementations: plain Java class for Session Facade usage or a stateless Session EJB for non‑EJB clients.

Advantages: enables entity EJB reuse, improves maintainability and performance, and provides a transparent, fine‑grained data interface.

Generic Attribute Access

Direct getter/setter calls become cumbersome when entities have many attributes. A Generic Attribute Access Interface uses a HashMap (or reflection for CMP beans) to read/write attributes dynamically.

Benefits: works for any entity, reduces code size, and allows runtime addition/removal of attributes.

Drawbacks: extra mapping overhead, required naming conventions, and potential type‑conversion errors.

Business Interface

To avoid mismatches between bean implementations and remote/local interfaces, a custom Business Interface defines all business methods, which both the bean class and the remote/local interface implement.

For remote interfaces, methods must declare throws java.rmi.RemoteException; local interfaces need no special handling.

Internal Data Conversion Strategies

Data Transfer Object

DTOs encapsulate multiple attributes for a single transfer, reducing network calls. Two models exist:

Domain DTO : one‑to‑one with an entity, useful for updates and creation.

Custom DTO : tailored to client needs, offering flexibility but potentially many classes in large projects.

Domain Transfer Hash Map

Uses a HashMap to package arbitrary data sets, offering good maintainability and broad applicability, at the cost of required mapping documentation and type‑casting.

Data Transfer RowSet

When handling raw JDBC ResultSets, a RowSet can be transferred directly, preserving tabular format without extra conversion.

Advantages: universal interface, no extra type conversion for display.

Disadvantages: exposes database schema, violates OO design, and depends on SQL.

Transaction and Persistence Mechanisms

JDBC for Reading Pattern

For read‑only data display, accessing the database directly via JDBC avoids the overhead of entity or Session EJBs.

Pros: leverages DB caching, reduces transaction overhead, allows custom SQL for flexible queries, and minimizes database round‑trips.

Cons: conflicts with OO design, embeds SQL in EJB code reducing maintainability, and requires knowledge of the DB schema.

Source: http://blog.csdn.net/guolong1983811/article/details/51195300