So, I've been following this discussion with interest. I'm still confused. All I'm really getting out of the comments on this thread is: there's some other objects in the system that aren't DAOs or entities
. But I knew that already. Clearly, I need to actually read the damn book for myself. Still, it really doesn't fill me with confidence that people who /have/ read the book don't seem to be able to explain (in words or code) the Repository notion coherently. And it looks like everyone has their own private take on what exactly a Repository is all about. This gives me a hint that the idea is not especially well-defined.
What I still need to hear from proponents of this idea is a clear accounting of:
- what problem does it solve?
- how do I tell when I need to use it?
- how do I tell which functionality belongs in the Repository, which on the Entity, and which on the DAO?
- what are the costs of using it?
And I want these folks to take seriously the following question:
Do we /really/ need another stupid layer in our already horribly over-engineered Java applications?
Enough layers already, goddammit! :-)
UPDATE: Fabio Kung has written a nice
explanation
of his understanding of the semantics of a repository, and there's nothing there
that I really object to. Except that, what he's describing is pretty much what
my understanding of the DAO pattern has /always/ been. I have never understood
that a DAO
was persistence specific from the point of view of the client. It's just a source of objects. Where it gets those object from is its own
business. I sorta thought that was the whole point...
