Comments on: On the subject of DAOs and Interfaces

By: Alexander

Alexander — Sat, 03 Mar 2007 06:09:13 +0000

Creating multiple interfaces makes a lot of sense from testing point of view. IF you want to creates a multi-tier architecture and at the same time make sure that it has significant test coverage (by using EasyMock or JMock frameworks) then this is the way to go.

In the long run it will minimize the cost of maintenance and simplify future development. IF this is a very small application, and from what you’ve described (six or seven DAO classes) then creating a complex multi-tier structure may be an overly expensive approach.

By: Chris Johnston

Chris Johnston — Tue, 06 Feb 2007 05:32:26 +0000

Interesting perspective and the more I think about it, the more I tend to agree. Some Ruby classes have in excess of 70 methods. Yet, in the Java world, that is seriously frowned upon for some reason (at least in my experience).

I like the point about being pragmatic. Good advice, thanks.

By: Irfan

Irfan — Sun, 04 Feb 2007 17:31:23 +0000

I would have one DAO for accessing the persistence layer. It doesn’t make sense to tie the persistence with the business logic either. And having too many interfaces does seem counter intuitive. “Just because you can have an interface doesn’t mean you should”. I think the question here lies with being pragmatic. Hibernate is a great tool. I would definitely consider using Hibernate and using one DAO that makes use of a class that manages the use of the Hibernate session. ie (HibernateUtil class).

I could see multiple DAO’s being used if you have a large schema but thats fine too. I would probably go with a large facade that delegates all those requests.
If you have a large number of methods then so be it. Again the notion of being pragmatic comes in again.

I’m finding that people seem to do a lot of things the hard way and like to complicate things. I think being pragmatic is very important here.