6

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.

Andrea Ligios
  • 49,480
  • 26
  • 114
  • 243
nicholas
  • 2,581
  • 14
  • 66
  • 104

2 Answers2

12

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.

squawknull
  • 5,131
  • 2
  • 17
  • 27
4

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.
Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Ralph
  • 118,862
  • 56
  • 287
  • 383
  • I agree with you. Therefore, i would like to ask which patterns is still required. – nicholas Apr 08 '11 at 07:13
  • @peterwkc: see my extended answer, I hope that general rule can guide you to find the "deprecated" patterns. – Ralph Apr 08 '11 at 07:29
  • Sorry to ask such a stupid question. Since pattern is intended to solve problem unless the problem is still exists, we should applied a specific patterns to solve the problem. – nicholas Apr 08 '11 at 08:21
  • @peterwkc: I do not understand your last question. -- A problem exits only in an scope/environment. If you change the scope/environment then the problem may or may not exits in the other scope/environment too. For example dividing 1 by 2 is a "problem" if you have only integers, but not if you have rational numbers. – Ralph Apr 08 '11 at 08:43
  • "For example, use injection instead of ServiceLocator." Not entirely true, you can use DI in the container managed objects in JEE 5 – Daniel Kec Apr 24 '14 at 05:45
  • Sorry to bother you guys, but I'd greatly appreciate your opinion about [this ECB pattern question](http://stackoverflow.com/q/26656302/1654265). – Andrea Ligios Oct 31 '14 at 15:35