Java EE 6 Design Patterns

I would like to know about the design patterns that can be applied in Java EE 6 implementation.

• MVC.
• GOF.
• DAO
• Persistent relational mapping
• Pooling
• CEC
• Entity control boundary (ECB)
• and many others

Do JPA eliminate the use of DAO?

Please provide other patterns that can be learned.

There is a good reference here: http://martinfowler.com/eaaCatalog/

Also here: http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

Also, JPA doesn't necessarily eliminate the need for a DAO layer. Instead, your DAO layer would still build the JPA queries, likely within finder methods, and return the entities that those queries returned.

You could eliminate the DAO layer, and instead hit the JPA entities directly within your business tier, but personally still like to maintain a separate persistence (DAO) and business tier, particularly in those cases where I end up having to mix up some JPA with plain JDBC, etc.

There is a great summary of the debate here. The best answer is that it depends. If your app is complex, and you may be accessing JDBC directly in some cases (because JPA and ORM tools are not the answer to everything, and are very bad at some things), or if you need to pull data from sources that just don't work well with ORM, you'll need a DAO layer anyway, so in my mind, I'd rather be consistent and use a DAO layer for everything. It's generally not that complex, and it isolates your business logic from your persistence logic, which I believe to be a good thing. But, it is a matter of personal preference, and if your app is suitably simple, it's probably overkill.

There is a good recommendation of a generic DAO pattern that can be used with JPA here. This allows you the benefits of a DAO in that you can always override this for a specific DAO, while keeping the more standard and typical database interactions simpler.

If you use Java EE 6 (not Java EE 5), then some of technical J2EE patterns are not needed anymore for the task they are used in J2EE.

For example, use injection instead of ServiceLocator.

@See http://pawelstawicki.blogspot.com/2010/07/review-real-world-java-ee-patterns.html

GOF patterns still required, because they are not (only) related to Java EE.

In general: Patterns have an intend: they want to produce a solution/best practice for an problem, with a given set of functionality that is proviced by the environment (In your case: it is Java, Java EE 6, ...)

• If the problem is gone a way: you do not need the pattern anymore
• If the environment has changed since the pattern is fond, then you have to rethink the pattern, because may the problem is gone (first point), or there is now a better way the handle the problem.