Data access architectures with Raven DB

What data access architectures are available that I can use with Raven DB?

Basically, I want to separate persistence via interfaces, so I don't expose underline storage to the upper layers. I.e. I don't want my domain to see IDocumentStore or IDocumentSession which are from Raven DB.

I have implemented the generic repository pattern and that seems to work. However, I am not sure that is actually the correct approach. Maybe I shall go towards command-query segregation or something else?

What are your thoughts?

回答1:

Personally, I'm not really experienced with the Command Pattern. I saw that it was used in Rob Ashton's excellent tutorial.

For myself, I'm going to try using the following :-

Repository Pattern (as you've done)
Dependency Injection with StructureMap
Moq for mock testing
Service layer for isolating business logic (not sure of the pattern here .. or even if this is a pattern.

So when i wish to get any data from RavenDB (the persistence source), i'll use Services, which will then call the appropriate repository. This way, i'm not exposing the repository to the Application nor is the repository very heavy or complex -> it's basically a FindAll / Save / Delete.

eg.

public SomeController(IUserService userService, ILoggingService loggingService)
{
    UserService = userService;
    LoggingService = loggingService;
}

public ActionMethod Index()
{
   // Find all active users, page 1 and 15 records.
    var users = UserService.FindWithIsActive(1, 15);         
    return View(new IndexViewModel(users));
}

public class UserService : IUserService
{
    public UserService(IGenericReposistory<User> userRepository, 
                       ILoggingService loggingService)
    {
        Repository = userRepository;
        LoggingService = loggingService;
    }

    public IEnumberable<User> FindWithIsActive(int page, int count)
    {
        // Note: Repository.Find() returns an IQueryable<User> in this case.
        //       Think of it as a SELECT * FROM User table, if it was an RDMBS.
        return Repository.Find() 
            .WithIsActive()
            .Skip(page)
            .Take(count)
            .ToList();
    }
}

So that's a very simple and contrived example with no error/validation checking, try/catch, etc... .. and it's pseudo code .. but you can see how the services are rich while the repository is (suppose to be, for me at least) simple or lighter. And then I only expose any data via services.

That's what I do right now with .NET and Entity Framework and I'm literally hours away from giving this a go with RavenDb (WOOT!)

回答2:

What are you trying to achieve by that?

You can't build an application which makes use of both an RDBMS and DocDB, not efficiently at least. You have to decide for yourself which database you are going to use, and then go all the way with it. If you decide to go with an RDMBS, you can use NHibernate for example, and then again - no need for any other abstraction layer.