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

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

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.