Question

With Repository pattern and ViewModels, how do you build queries against the database if you don’t want the raw database objects to leak outside the repository? How do I actually create queries without loading ALL the database in memory and using LINQ to Objects? I can’t expose IQueryable to the rest of the app.

For example, with EF I have a bunch of POCOs with several properties that match db fields, but also some stuff to work around enums not being directly support (for now) as well as foreign key IDs to prevent N+1 and easier querying and so on. I don’t want them to leak out to the rest of the application, I want the application to just see a normal object graph.

public class DbUser
{
    public int Id { get; set; }
    public string Name { get set; }

    public int GroupId { get; set; }
    public DbGroup Group { get; set; }

    public ICollection<DbComment> { get; set; }
}

public class User
{
    public int Id { get; set; }
    public string Name { get set; }

    public Group Group { get; set; }
    public ICollection<Comment> { get; set; }
}

The problem here is my repository will internally use EF for the querying (and in-memory stuff when unit testing). But how do I implement IQueryable<User> FindAll()? I can’t just do return dbContext.Users.Select(u => new User(u)), as in that case I lose all possible query ability; it’ll just load the whole user collection in memory, convert all the types to User from DbUser and then build LINQ queries on the in-memory collection – that is horribly inefficient.

I can’t just build queries in the repository. On some pages I have queries that select a few fields, but also calculate some complex stuff from other related objects, filter them based on the result (for example count of comments with positive score), but I also need that back in the application. I could select all objects used to get the complex stuff and return them to the application (but not as db entities) but that would mean select a LOT of data.

Basically how do I prevent the database entities from polluting the rest of the application with their cruft and hacks, while still maintaining the ability to build queries outside of the repository?

Answer 1

CQRS (Command Query Responsibility Segregation) solves this problem. You have the ‘real’ model , the Domain model, with all the business rules and all that, and a ‘query-ony’ model which basically is a simple poco (which can be used directly by Views) that will be returned by a specialised query only repository.

The peristence model (EF entities) are used only to ‘talk’ with the db, the repos always returns or deals with domain/ application objects. Basically, you have to map the EF entities to the Domain ones (and viceversa when saving). In this way, you’ll have separated models each with its own purpose.