Implementing the repository and service pattern with RavenDB

Question

I have some difficulties implementing the repository and service pattern in my RavenDB project. The major concern is how my repository interface should look like because in Rave

Answer 1

I would actually discourage you from using the repository pattern. In most cases, it is over-architecting and actually makes the code more complicated.

Ayende has made a number of posts to that end recently:

• http://ayende.com/Blog/archive/2011/03/16/architecting-in-the-pit-of-doom-the-evils-of-the.aspx
• http://ayende.com/Blog/archive/2011/03/18/the-wages-of-sin-over-architecture-in-the-real-world.aspx
• http://ayende.com/Blog/archive/2011/03/22/the-wages-of-sin-proper-and-improper-usage-of-abstracting.aspx

I recommend just writing against Raven's native API.

If you feel that my response is too general, list some of the benefits you hope to gain from using another layer of abstraction and we can continue the discussion.

Answer 2

Let's say I need to fetch all items where the parentid equals 1.

First, stop thinking of your data access needs this way.

You DO NOT need to "fetch all items where the parentid equals 1". It will help to try and stop thinking in such a data oriented way.

What you need is to fetch all items with a particular parent. This is a concept that exists in your problem space (your application's domain).

The fact that you model this in the database with a foreign key and a field named parentid is an implementation detail. Encapsulate this, do not leak it throughout your application.

One way is to use the IQueryable List() and get all documents and then add a where clause to select the items where the parentid equals 1. This seems like a bad idea because I can't use any index features in RavenDB. So the other approach is to have something like this, IEnumerable Find(string index, Func predicate) in the repository but that also seems like a bad idea because

Both of these are bad ideas. What you are suggesting is requiring the code that calls your repository or query to have knowledge of your schema.

Why should the consumer of your repository care or know that there is a parentid field? If this changes, if the definition of some particular concept in your problem space changes, how many places in your code will have to change?

Every single place that fetches items with a particular parent.

This is bad, it is the antithesis of encapsulation.

My opinion is that you will want to model queries as explicit concepts, and not lambda's or strings passed around and used all over.

You can model queries explicitly with the Specification pattern, named query methods on a repository, Query Object pattern, etc.

it's not generic enough and requires that I implement this method for if I would change from RavenDB to a common sql server.

Well, that Func is too generic. Again, think about what your consuming code will need to know in order to use such a method of querying, you will be tying upper layers of your code directly to your DB schema doing this.

Also, if you change from one storage engine to another, you cannot avoid re-implementing queries where performance was enough of a factor to use storage-engine-specific aids (indexes in Raven, for example).

Answer 3

This post sums it all up very nicely:

http://novuscraft.com/blog/ravendb-and-the-repository-pattern

Answer 4

First off, ask why you want to use the repository pattern?

If you're wanting to use the pattern because you're doing domain driven design, then as another of these answers points out, you need to re-think the intent of your query, and talk about it in terms of your domain - and you can start to model things around this.

In that case, specifications are probably your friend and you should look into them.

---

HOWEVER, let's look at a single part of your question momentarily before continuing with my answer:

seems like a bad idea because it's not generic enough and requires that I implement this method for if I would change from RavenDB to a common sql server.

You're going about it the wrong way - trying to make your system entirely persistence-agnostic at this level is asking for trouble - if you try hiding the unique features of your datastore from the queries themselves then why bother using RavenDB?

A method I tend to use in simple document-oriented (IE, I do talk in terms of data, which is what you appear to be doing), is to split up my queries from my commands.

Ask yourself, why do you want to query for your documents by parent ID? Is it to display a list on a page? Why are you trying to model this in terms of documents then? Why not model this in terms of a view model and use the most effective method of retrieving this data from RavenDB? (A query over an index (dynamic or otherwise)), stick this in a factory which takes 'some inputs' and generates 'the output' and if you do decide to change your persistence store, you can change these factories. (I go one step further in my ASP.NET MVC applications, and have single action controllers, and I don't call them controllers, making the query from those in most cases).

If you want to actually pull out your documents by parent id in order to update them or run some business logic across them, perhaps you've modelled them wrong - a write operation will typically only involve change to a single document, or in other words you should be modelling your documents around your transaction boundaries.

TL;DR

Think about what it is you actually want to achieve - why do you want to use the "Repository pattern" or the "Service pattern" - these words exist as ways of describing a scenario you might end up with if you model your application around your needs, as a common way of expressing the role of a certain object- not as something you need to shoehorn your every piece of functionality into.