Pros and cons of the use of the DAO pattern [closed]

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?

Ormuz

For sure beats no pattern at all unless it's a hello world app:P – Weiler

subjective questions must be wiki, at least – Erinn

I am surprised at the implication reflected in the answers below that the DAO pattern presupposes a hand crafted data access implementation. This is certainly not my understanding. It seems to me that the DAO pattern delivers separation of concern whether using an ORM or straight JDBC. – Pelayo

@Malcolm: Hey, how about ODBC etc? Anyway I agree to your points :) – Weiler

Answer 1

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.

Thingumabob

That was the reason of my initial question, thanks for the answer. ANd I have another question: What about to have static factory methods instead of a constructor within the Value Objects, and for that specialized queries try to build a kind of 'query wrapper' within the object. Do you think maybe is a good option? I imho thinks it can bring performance optimization, but I'm not sure, what do you think? – Ormuz

I think that it can bring performance optimization, but it needs to be handled in a consistent manner. For instance, how are the factory methods going to access the data store? Would you pass in this information into a constructor, use a static class that holds the information, or what? A factory pattern may be better here in that you can have multiple methods to create objects on the interface where you can use whatever you've configured behind the scenes. – Thingumabob

OK, I will work through your idea, to see – Ormuz

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.

Womanish

handwriting... pro: pretty easy (or at least straight forward) to auto generate the source code from an existing database schema. – Augustaugusta

Answer 3

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.

Kliment

So what's the difference between DAO and Repository pattern then? – Bagpipes

Answer 4

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.

Insipience

What does having a Data Access Layer have to do with DAOs? We use fat models in Rails, and all data access is done through the models, too. Still, the set of models form the DAL without being DAOs. That's a very common pattern in Rails (and other) web apps. – Lacy

Well, I'm not sure I get your question but, to me, a Data Access Layer (DAL) might be composed of multiples DAOs. This is a very common pattern in Java that doesn't have everything that Rails offers (e.g. active record). – Insipience

Answer 5

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

Pelayo

Answer 6

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.

Valaree

Sure, I was talking about hand-coded DAO (With VOs and all that stuff) vrs Hibernate or something like that. I'm not sure about this, but I have had some problems when trying to use Hibernate or something like that and trying to define Many-To-Many relationships... So is always good to see the other options. – Ormuz

Answer 7

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

Jolynjolynn

Answer 8

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.

Hardigg

> developers don't get to invent their own wheels (might be a PRO :-)) Its definitely a pro. There's a lot of wheels out there already. – Bissextile

@Rui: oh well, silly me trying to add a bit of humor. Of course it is a pro (missed the :-)?), some developers' version of the statement is that a DAO pattern is not "flexible" enough and present it as a CON. – Hardigg

I also hear that from a friend of mine, a DB 'expert'... And I don't clearly understand such a different way to see it. Thanks for the answers! – Ormuz

Up-voted for good use of the word sexy! And because the answer makes sense. – Mazur