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.

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.

Benefits of using DAO design pattern

DAO or Data Access Object design pattern is a good example of abstraction and encapsulation object oriented principles. It separates persistence logic is a separate layer called Data access layer which enables application to react safely to change in Persistence mechanism. For example, if you shift from File-based persistence mechanism to Database, your change will be limited to data access layer and won t impact Service layer or domain Objects. Data Access Object or DAO pattern is pretty much standard in Java application being it core Java, web application or enterprise application. Following are couple of more benefits of using DAO pattern in Java application:

1. DAO design pattern also keeps coupling low between different parts of an application. By using DAO design pattern your View Layer is completely independent of DAO layer and only Service layer has the dependency on it which is also abstracted by using DAO interface.

2. DAO design pattern allows JUnit test to run faster as it allows to create Mock and avoid connecting to database to run tests. It improves testing because it s easy to write test with Mock objects, rather than an Integration test with the database. In the case of any issue, while running Unit test, you only need to check code and not database. Also shields with database connectivity and environment issues.

3. Since DAO pattern is based on interface, it also promotes Object oriented design principle "programming for interface than implementation" which results in flexible and quality code.

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.

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).

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.

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

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
• developing 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 of 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, depending on your situation using a persistence framework might be a good alternative to coding your own DAO s.