Dumb data buckets.

They are known as Value Objects, Data Objects, and now Sun calls them Transfer Objects. You only need these if you are doing EJB right? Is there any reason to have your DAO interfaces return Transfer Objects rather than full-fledged "Business Objects" or "Domain Objects" or whatever you call them. I think the answer is NO.

I'm sure this will upset any remaining EJB fans out there: even if you are doing EJB, you can hide the EJB/Transfer object mess behind a set of DAO interfaces.

DAO comments.

I've gotten a number of responses on my DAO post. Thanks to all who responded. I think the general consensus is that DAO is a useful pattern, but it can limit your ability to make use of all of the cool features of your persistence framework. I'll try to summarize the responses for you below:

Rickard Oberg says DAO is a useful pattern, but he has not tried to implement it a O/R framework before. Somewhat predicably, he adds that Aspect Oriented Programming (AOP) can play a role in improving DAO implementations.

Jason Carreirra says that the problem with DAO is that it requires fine grained objects, and that this makes it difficult to "streamline data access with bulk loading and caching."

Matt Raible says DAO works well, but does not like having to modify so many files just to add one field to an object. He'd like to automate the whole process with end-to-end code generation.

Russell Beattie reminds us of his complexity of J2EE post, but unlike Matt he says that tools and automation are not the answer - we need a better pattern.


All I can say is WOW! and where can I get the source? UPDATE: now that I am fully awake, I should add this: thanks to Mike Cannon Brookes, Atlassian, and whoever else contributed to the java.blogs community aggregator website. What an awesome resource and this is just the start of it!

Main | Next day (Nov 28, 2002) »