Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is DAO pattern an obsolete pattern

 
Varun Chopra
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is DAO pattern an obsolete pattern now-a-days, no need of it now. But why, what is the reason, nobody talks about that. Can you give your insight?
 
Joe Matthew
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Whats a DAO Pattern?

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 ]
 
Varun Chopra
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Eric Nielsen
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It depends.

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.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This thread might be of some interest.
 
Varun Chopra
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm...Ok, I will go through DDD in detail.....
but is a there is a short statement that will summarize "the basis of deciding a repository"?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic