On the subject of DAOs and Interfaces
Over the last little I have been wondering about this whole design principle of designing to interfaces and not concrete classes. I have no problem with the principle; people far more experienced then me created it. I do have a small question though: when using the DAO pattern, how do you stop from having an explosion of Interfaces?
The last project I was working on had about 6 or 7 DAOs. Each of these DAOs implements an interface. That means that for each class in the persistence layer there was an interface and a concrete implementation. For each interface there is only one class and there will probably only ever be one concrete class implementing each interface.
So, my simple question is: does this make sense? This pattern also shows up in other layers and parts of the code. I understand the need for interfaces and the need to hide the parts that change behind an interface or abstract class, but putting an interface in front of almost every class that exposes a public interface makes no sense to me. How do other people expose their DAOs to the rest of their applications?
So far two solutions have come to mind. The first is to use the Facade pattern and hide several related DAOs behind a single class that implements a single interface. The second solution is to not use the DAO pattern. The first solution makes a lot of sense to me, but my fear is that it could result in facades with a very large number of methods.
I am not sure about the second method. The only way of implementing that makes any sense is by following Rails and moving the responsibility for saving, updating, and finding objects into the domain model and out of the persistence layer. This means that each domain object would be responsible for saving, updating or finding itself. Which on one level makes a lot of sense; however, it ties the persistence of those layers into one technology such as a Hibernate.
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.
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.
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.