I linked to an article outlining a generic DAO design a little while back. It had some good points, but today as I was reading some mail from the Domain Driven Design group I started thinking again. One of the guys there suggested to view the Repository/DAO as a collection. You can’t just narrow it to that, but you could grab the base concepts. It would provide methods something like this:
- add – insert / register object with unit of work
- remove – delete
- merge – update/merge detached db objects
- get* – retrieve single objects based on criteria
- find* – retrieve collection of objects based on criteria
You see some differences between “stateful” and “stateless” implementations of the DAO layer in the methods above, but they are minor and I actually think this should be a good pattern that most people can grasp easily.
One reply on “DAO layer design”
Since an OODMS looks like a collection of objects to an application, this approach does have some merits. Better this then using DTO over DAO. That idea should actually be considered an anti-pattern