Phillip Calçado: "More and more I’ve seem the Repository been used as a fancy name for DAOs. It is very common nowadays to have things named Repository that create SQL/HQL/EJBQL queries or deal with database transactions or connections. Only a DAO with a different name."
The intent of a Repository is to abstract out the kind of storage you are using, not just the details of a particular relational database. What the Repository isa Dao interface gives a developer is a structural decoupling from the database, so you can use HSQL or Mocks for testing, or support multiple backends in production, but it still has the assumption that you are using "One Relational Database" and that tends to mean in code each supposed Repository is mapped onto tables.
Reducing the concept of a Repository to a DAO isn't helpful. It means the industry (or maybe just Spring ;) will need to introduce a third concept down the line or redefine what was meant by "Repository". Granted it doesn't help that the Repository pattern in Domain Driven Design isn't well explained, and you can argue that there's nothing inherently "per table" in
the DAO or DataMapper patterns, but in reality that's how most of us
them.
Recently in work I did an extended spike on what will be a shared data system in our products. It'll get called heavily so it probably 'Needs To Scale' and perhaps support functional splits, in practical terms that meant keeping an eye on the data joins. For that reason I started the spike with Hibernate shards. What I found is that the Repository-isa-DAO approach falls apart when you need to either carefully order the serialisation sequence to put related data on the same physical partition or where you're organising your relational data to be treelike with minimal joins (so it could in principle be functionally split later). Normally that logic would be exposed in Domain Facade and per object save methods; the problem with sharding is that you can call saves out of order in what otherwise would be reasonable code. In my case what I found was that Hibernate Shards was putting objects that should be related to each other on different shards - not good! Some quick fixes later and I had the corrected the persistence layer, by making sure the object graph was properly cued. All that logic had to pushed back behind an interface - the Repository. And this is where the Repository abstraction shines, especially in conjunction with Builders. You give the Repo an object graph and it takes care of the serialisation, the physical allocation of data, and removes the assumption you're using a single relational database. DAOs by contrast don't remove the single database assumption. I suspect that unlike DAOs, Repositories are part of the domain and not a detail of persistence mechanism
And of course it should to be said that if you are building on a single database (and that's most of us, most of the time), DAO/DataMapper are enough of an persistence abstraction and Repositories are probably pattern noise - use a DomainFacade and move on.
Previous Topic
