Query Objects: a better approach than your BLL/repository
If you’ve been following what I’ve been saying here on my blog and on the ASP.NET forums over the past month or so, you’ll no doubt realise that I’m not a fan of the traditional layered architecture, with your presentation layer only allowed to talk to your business layer, your business layer only allowed to talk to your repository, only your repository allowed to talk to your ORM, and all of them in separate assemblies for no reason whatsoever other than That Is How You Are Supposed To Do It. It adds a lot of friction and ceremony, it restricts you in ways that are harmful, its only benefits are unnecessary and dubious, and every implementation of it that I’ve come across has been horrible.
Here’s a far better approach:
public class BlogController : Controller
{
private IBlogContext _context;
public BlogController(IBlogContext context)
{
_context = context;
}
public ActionResult ShowPosts(PostsQuery query)
{
query.PrefetchComments = false;
var posts = query.GetPosts(_context);
return View(posts);
}
}
[Bind(Exclude="PrefetchComments")]
public class PostsQuery
{
private const int DefaultPageSize = 10;
public int? PageNumber { get; set; }
public int? PageSize { get; set; }
public bool Descending { get; set; }
public bool PrefetchComments { get; set; }
public IQueryable<Post> GetPosts(IBlogContext context)
{
var posts = Descending
? context.Posts.OrderByDescending
(post => post.PostDate)
: context.Posts.OrderBy(post => post.PostDate);
if (PrefetchComments) {
posts = posts.Include("Comments");
}
if (PageNumber.HasValue && PageNumber > 1) {
posts = posts.Skip
((PageNumber - 1) * (PageSize ?? DefaultPageSize));
}
posts = posts.Take(PageSize ?? DefaultPageSize);
return posts;
}
}
A few points to note here.
First, you are injecting your Entity Framework DbContext subclass (the implementation of IBlogContext) directly into your controllers. Get over it: it’s not as harmful as you think it is. Your IOC container can (and should) manage its lifecycle.
Secondly, your query object follows the Open/Closed Principle: you can easily add new sorting and filtering options without having to modify either the method signatures of your controllers or its own other properties and methods. With a query method on your Repository, on the other hand, adding new options would be a breaking change.
Thirdly, it is very easy to avoid SELECT n+1 problems on the one hand while at the same time not fetching screeds of data that you don’t need on the other, as the PrefetchComments property illustrates.
Fourthly, this approach is no less testable than your traditional BLL/BOL/DAL approach. By mocking your IBlogContext and IDbSet<T> interfaces, you can test your query object in isolation from your database. You would need to hit the database for more advanced Entity Framework features of course, but the same would be true with query methods on your repository.
Fifthly, note that your query object is automatically created and populated with the correct settings by ASP.NET MVC’s model binder.
All in all, a very simple, elegant and DRY approach.
(Hat tip: Jimmy Bogard for the original inspiration. This version simply adds the twist of having your query objects created and initialised by ASP.NET MVC’s model binder.)
Posted at 08:00 on 21 August 2014.