Pros and cons of the use of the DAO pattern [close

Question

As I mention in the title, I'm interested to know what you (as experienced developers) think about the use of the DAO pattern, specifically within a web application. What advantages have you found and what consequences of its use have you disliked?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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 5

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 6

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.