I’m currently experimenting with MongoDB. I’m moving from a NHibernate/SQL mindset, and so initially I implemented a repository pattern for data access.
This was all looking fine until I started using nested documents. Now it’s starting to seem like there’s a bit of a mismatch. However, I’m comfortable with repositories, and like the abstraction, separation of concerns, and testability they provide.
Are people successfully using the repository pattern with document databases? If not, what data access methodology to you use? What about abstraction/SoC?
It’s an interesting question. In my usage of MongoDB, I chose to not have a repository. This was primary because the document database was used as a read store (therefore simplifying the data that was stored there).
I guess you have to strip the consideration back to what a repository is and what advantages you get from the extra layer of abstraction. A good design will have the least number of layers possible.
A repository therefore gives you some persistence ignorance and the ability to use unit of work over a common context of data. It also can increase your ability to test queries against the data in isolation (because these are usually abstracted as queryables or specifications).
Also, some document databases already provide a repository pattern (RavenDB etc), so there is no need to have yet another layer.
So, it seems to me that using a repository is not so much about whether your data is stored as a relational table or a document, but more about what you gain from the abstraction.