Pros and Cons of the use of DAO pattern

Question

As I mention, I'm interested to know what do you (as experienced developers) thinks about the use of DAO pattern, specifically within a Web Application. If possible what advantages have you found, or consequences of it use.

Thanks.

Answer 1

The forces of the DAO pattern are that they allow you to create a nice abstraction layer of the actual storage system. They provide a more object-oriented view of the persistence layer and a clean separation between the domain and the code that will actually perform the data access (straight JDBC, persistence frameworks, ORM or even JPA).

If I had to cite a weakness, well, I'd say it's another layer... But I guess this is the price to pay to not tie your code to the underlying persistence API.

Answer 2

NOTE: you might find other shortcomings, but here is a quick list from my experience

PROS:

• Common calls to retrieve objects.
• Once you have the general create/read/update/delete flow set, the general layout can be repeated for other DAOs.
• It also consolidates where the persistence specific portion of your code can go. Separates the business logic from other components of your code.

CONS:

• It is not the most flexible thing ever.
• If you want to lazy-load some child objects, then you are going to have to either intermingle the DAOs with other layers or take precaution when attempting to retrieve the lazy objects.
• If you handwrite the DAOs, then the code can become tedious and repetitive.

Answer 3

What alternative are you considering?

It seems pretty obvious that placing responsibility for persistence somewhere other than the presentation tier will usually be good, just from arguments of clarity of responsibility and reuse. I instinctively go for a three layer approach: Presentation, Service, Persistence. Confess to having been doing it this way for so long that I can't aduce evidence of pain suffered by not doing it that way. To me it seems "obvious" that having a single layer which understands the persistence mechanism must simplify testing, ease maintenance and give a good separation of concerns.

So that leaves the question of exactly how to do the persistence layer. My default assumption would be to use JPA (or similar frameworks). I do view this as a sophisticated example of DAO.

So I see two costs of DAO. First you need to invest in your program structure, its design. For trivial cases this may feel like overkill. Second if you use a framework that implements DAO for you there is a learning curve. Compared with just writing the JDBC code directly this is another investment.

Answer 4

We have seen some real benefit in introducing a DAO pattern into our implementation. This due mainly to the clear separation between database interface and implementation. We have observed the following benefits:

• Abstraction for actual database access implementation separates the data access strategy from the user business logic. This has allowed us to choose a short term (Spring JDBC Template) implementation strategy for the initial project phase with the option to move to IBATIS or Hibernate at a later date. (A choice we are not in a position to make at this time.)
• The separation introduces significant testability benefits in that the entire data access implementation can be mocked out in unit testing. (This is probably the biggest benefit)
• Combining this with Spring allows us to inject any DB implementation into the system we choose (although this possibly says more about DI than the DAO pattern).

One issue that we encountered, and this may be due to a lack of clarity of design on our part is the "inclination" to reuse the Data Value Objects published out of the database as Transfer Objects between the subsequent abstraction layers in the architecture. Our solution after some pain was to have a value object per layer (i.e. to not reuse the database value objects in subsequent architectural layers).

Answer 5

Pro: abstract separation.
Con: boilerplate code (thank god for code generators/templates and ORM's).

Answer 6

DAO pattern is completely useless for web development!

Answer 7

PRO

• single point of definition for DB table - Object attribute mapping
• transparent possibility for DAO implementations to other storage types
• develop an interface pattern all DAO's follow
• develop a more or less standard JUnit test class for DAO's results in better test coverage
• full control over specifics
• no performance loss due to an overly generic solution

CON

• less "sexy" than using the latest framework
• developers don't get to invent their own wheels (might be a PRO :-))

As with most development patterns, using DAO's takes some time to get used to. With experience comes the benefits in more robust code and developers that know why things work, not just that it seems to. That last point is the biggest advantage for me.

Caveat, perdending on your situation using a persistance framework might be a good alternative to coding your own DAO's.

Answer 8

The problems with DAOs that I have seen is that they typically handle full objects all the time. This creates completely unneeded overhead that wouldn't exist with simple queries. For example, if a drop down is to be created off of database reference data, a DAO user may simply say: "Get me the collection of objects for this table where y ordered by z". Then, that data is used in the dropdown, but typically only for a key/value combination, ignoring everything else in the objects (created data, last user who updated it, whether or not it is active, etc) that was retrieved and mapped. Even if this massaging happens near the DAO call and the objects do not get stored as they are retrieved (which is typically not the case, unfortunately, the objects are often wrapped in a c:forEach (JSP) and iterated over to produce a drop down), it still creates unneeded database and network overhead, not to mention the temporary increase in memory to hold these objects.

Now, this is not to say that a DAO can't be designed to retrieve a Map of reference data - it certainly can. But typically they're used for the full object mapping, which is not what is needed all the time. It is a strength when saving, but a weakness, IMO, when retrieving data - sure, you get all of it - but often you don't need all of it, and it just wastes memory, bandwidth and time.