DAO: use or don't use, is the question

[Fabio Medeiros Faria]

I'm adherent to use the pattern DAO as a specific layer in the application. But I have seen many discution about this question, some arguments show this pattern in nowadays isn't more necessary, because technologies as JPA are well matured.

One this discussions borned in a post with my simple blog, www.serjava.blogspot.com, and although I advocate the pattern DAO I would like to know what are you think?

[]s

[Tim Holloway]

I use DAOs, and an additional level (persistent services) and the more I use them, the more convinced of their utility.

My DAOs are classes that encapsulate all of the single-table persistency operations for my ORM. That is to say that they implement the save/update/delete methods and the finder methods. They have an ORM EntityManager injected into them, and they are the layer in which all of the query language statements are defined and used.

This makes it easy to locate and test primitive persistency operations. In particular, I can set up and unit-test the query language-based functions, which is very important, since QL is interpreted at run-time and there are lots of ways to create QL that look OK, but fail when used, because they refer to mis-spelled object model property names, properties that don't exist in the schema for one reason or another (renamed or deleted), and joins that can't join. And, for that matter, queries that return incorrect results.

As I said, I use another tier as well. In this tier I have my business-oriented persistency logic. The methods in these classes deal with interrelated tables all being manipulated under a single database transaction. They invoke DAOs to do their dirty work, but the business of keeping the related objects properly related is theirs, as is any last-minute validation that can only be done when you see the table working set as a unit. To keep things clean, they echo DAOs when simpler operations are required so that the actual non-transactional business layer (and all higher layers) never see the DAOs directly.

By employing this separation of concerns I can do persistent data management cleanly and reliably and I'll always know where to look for a given functionality.

[Fabio Medeiros Faria]

Tks Tim, I agree with you!

I think the pattern DAO is perfect to maintenance the high cohesion in the code. Its simplify the use of the better practices and most efficient test tools, providing tests of the layer persistence clearly, as dbUnit, for example.

Tks for write your opinion.

I would like if you can access my simple blog, it is in portuguese, but the google translator can help you.

[Mark Heron]

Tim,

In my application most of screens are showing data from two or more tables. Most of time we don't just query single entity. In such scenario should we use similar design? Is there any better approach? Are you performing table joins in higher level business tier using HQL / SQL? Also are you eager fetching all required data in business service?

Thanks

[Tim Holloway]

Mark Heron wrote:Tim,

In my application most of screens are showing data from two or more tables. Most of time we don't just query single entity. In such scenario should we use similar design? Is there any better approach? Are you performing table joins in higher level business tier using HQL / SQL? Also are you eager fetching all required data in business service?

Thanks

Yep, that's exactly the kind of stuff I meant. Although a lot of people keep an open link all the way through the page-rendering process, I consider this to be sloppy (and a bit hazardous), so my service-layer methods return detached objects.

I usually do my joins using ORM object references, but depending on how the object model was set up and used, I may also employ other methods, including joins and secondary queries.

For the stuff I do, there's almost always a "working set" of related objects used by the business layer code and the service methods are responsible for assembling and updating them, typically by reference to an anchor object. Mostly I have the actual ORM object model set to do a Lazy Fetch and the DAO will have a "findWithChildren" or "findWithDependency" method that instigates forced-fetch when I need it.

[David Sachdev]

What are your thoughts on the Repository pattern versus typical DAOs?

I'll include Martin Fowler's diagram for those who may not be familiar:

http://www.martinfowler.com/eaaCatalog/repository.html

The idea of having persistence handled closer to the domain with one or many repositories to me is very appealing in this day and age of ORMs that can also handle generic types because a DAO per entity reminds me of boilerplate code that I hope much of the community has been working hard to get rid of since the dark days of computing (J2EE/COM/DCOM/...). The idea of keeping most of your code related to the business logic appeals to me, and I believe that in most cases a Repository versus the typical DAO helps along those lines. Thoughts?

Looking forward to your opinion, as we make some similar decisions on a project that I am working on where people are coming from different backgrounds.

[Tim Holloway]

As a rough approximation, Fowler's "Repository" corresponds to my service layer and his "In memory strategy" corresponds to the DAOs, although I don't like the name employed, since it sounds too much like caching, which is another process altogether, and is usually best done transparently by a third-party generic subsystem.

I have been known to use template classes to reduce the "boilerplate" aspect of DAOs, although Java's implementation of templates makes this more awkward than it should be. Attempting to fold the DAO functionality into the business persistence functionality has generally been messy. I started that way, and only gradually determined that systems were more maintainable when I kept the two functionalities segregated.

For smaller endeavors, such things are not essential, but as things get more complicated, it starts to pay off. I have one system that has 1 online app, about to become 2, plus several batch utilities. That one actually has 3 distinct assembly layers: the ORM model/DAOs, the services module, and the application modules themselves. Basically, that's what EJBs were originally engineered to be for and so rarely actually needed to be.