It depends on what you require in your application. People tend to accept a common concept and apply it for all. Interfaces are used for standardization and you would want to have a abstract class implementing the interface. Use case specific DAO will be implementing the abstract class. It will look good.
The one main benefit you will get is that you can handle the same DAO call in the generic handler. Imagine you have execute abc() function for all DAO classes. This abc() is declared in the interface. You create the Use Case specific DAO class and assign it to the interface variable. Then you can use a generic class to process all your DAO implementations by DAOInterface.abc().
Makes a lot of sense when you use Spring and BusinessDelegates etc. [ July 10, 2008: Message edited by: Joe Mathew ]
Regards,<br />Joe<br /> <br />"Always program as if the person who will be maintaining your program is a violent psychopath that knows where you live."<br />--Martin Golding
Joined: Jul 10, 2008
Thanks for reply Joe, yes I get what you said....and I get the benefit of using interfaces in this scenario (the AbstractClass implementing the DAO interface). I have one more question. I read somewhere that
"one DAO class per table is not efficient and it is tightly couping DAO to the table structure. But with ORM mapping available now we do not need to do that anymore."
Instead we can group multiple DAOs into single DAO or something like that.
But the question is, if I join a project team and I look into their existing code, if I have to look for persistProduct method, I will obviously try to look into ProductDAO. But if there's no ProductDAO because multiple tables are clubbed into a single class, how will one know it? What's the benefit of clubbing? Is it only saving a few classes?
Can you point me to a blog/tutorial which talks about it?
If you're using a semi-standard DAO architecture you'll have one DAO per object class. Your program doesn't care about how many tables back that class in the database. This to me is just the "Object Mapping" versus "Object Wrapping" approach to persisting objects. So yes you'd still look for the "persistProduct" method on ProductDAO (though I'd say I'd be more inclined to call the method simply "persist"... The advantage is that your object model is decoupled from your persistence model -- often at very little cost if you're taking advantage of any of the modern ORM solutions.
Or you could be following a more Domain-Driven Design model of Repositories. Where, yes you'd only have many fewer Repositories than domain classes (and fewer domain classes than database tables). However in a DDD inspired design the Repositories are first class objects in their own right and it should be very easy to understand which one to go to when, when you need information. It does require grokking the concepts of Aggregates first though.