adam bien's blog

Patterns are clearly defined as:

"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design."

If you encounter a design challenge, you are supposed to search in a catalog for the description, compare the Motivation (Forces) or Applicability. If they match, you can apply the ideas from the pattern to solve your problem. Patterns are not a genius solution to a problem, rather than a standardized compromise. Usually you are going to implement flavors of the design patterns without even knowing it.

In Java Enterprise community patterns seem to have their own live. They are going to be applied regardless their problem definition or context. The most misused pattern in the Java Enterprise community is the DTO. DTO was clearly defined as a solution for a distribution problem. DTO was meant to be a coarse-grained data container which efficiently transports data between processes (tiers). In J2EE DTO was absolutely necessary, CMP Entity Beans were not serializable. Martin Fowler also defines defines DTO as:

"An object that carries data between processes in order to reduce the number of method calls."

Even more suspicious is the popularity of the DAO pattern. The solution statement starts as:

"The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP) or low-level sockets."

DAO was always meant as a procedural encapsulation of inconvenient or not standardized data sources. An object oriented flavor, the Domain Store pattern uses DAO to access JDBC and provides an object oriented access to the store. Interestingly the Domain Store looks like a slightly modified version of the ...JPA Entity Manager.

Some projects are wrapping Entity Manager with an empty delegate and call it "DAO". Such an approach is actually the opposite of the origin intention...

Java EE 5 killed the majority of the J2EE Patterns. Their "Problem" and "Forces" descriptions do not apply any more. Java EE 6 and 7 killed the remaining patterns, only the Application Service is still useful.

If you take the pattern definitions seriously and look at some "enterprise" projects you are not going to understand the design. Patterns are going to be applied without having a problem and are considered as future "insurance": "...in case JPA disappears, I only have to change the implementation of the DAO..."

How to deal with patterns? Apply them if you encounter a problem. Java EE design is "bottom-up" rather than "top-down", as it was the case in the old J2EE world.

[See also an in-depth discussion in the "Real World Java EE Night Hacks--Dissecting the Business Tier" book, page 259 in, chapter "Data Access Object"]