Java EE 6 Design Patterns

Question

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

• MVC
• GOF
• DAO
• Constant Relational Mapping
• Storage
• Cec
• Facility Management Boundary (ECB)
• and many others

Does JPA eliminate the use of DAO?
Please provide other templates that you can study.

Answer 1

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

For example, use injection instead of ServiceLocator.

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

---

GOF templates are still required because they are not (only) associated with Java EE.

In general: Templates have an intention: they want to create a solution / best practice for a problem with a given set of functions that are surrounded by an environment (in your case, Java, Java EE 6, ...)

• If the problem goes away, you no longer need a template
• If the environment has changed since the template gets carried away, you need to rethink the template because the problem may disappear (first point), or now there is a better way to deal with the problem.

Answer 2

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

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

In addition, JPA does not necessarily eliminate the need for a DAO layer. Instead, your DAO layer will still generate JPA queries, probably in search methods, and return the objects returned by those queries.

You can eliminate the DAO layer and instead access JPA objects directly in your business layer, but personally still prefer to maintain a separate persistence (DAO) and business layer, especially when I have to mix some JPAs with plain JDBC etc.

There is a great summary of the discussion here . The best answer is that it depends. If your application is complex and you can directly access JDBC in some cases (because the JPA and ORM tools are not the answer to everything, and for some things are very bad), or if you need to extract data from sources, "Work well with ORM, you still need a DAO layer, so in my opinion, I would prefer to be consistent and use the DAO level for everything.Normally, it’s not so difficult and it isolates your business logic from your persistence logic, which, like I think is a good thing. But, this is a matter of personal preferences, and if your application is simple enough, it is likely to be redundant.

There is a good recommendation for a generic DAO pattern that you can use with JPA here . This allows you to take advantage of the DAO in that you can always override this for a specific DAO, while maintaining a more standard and typical interaction with the database.