This is a follow up post to my YouTube video
Repository Pattern, Done Right. If you haven’t seen this video, it’s best to watch it first, before continuing reading.
There have been many interesting questions in the discussion area and I’ve replied to most (if not all) of them. One that has come up a few times is:
Should we favour command/query objects over repositories?
A few have referred me to
Jimmy Bogard’s post. So, in this post, I’ll be comparing these two approaches and pros / cons of each.
Before I get started, I need to emphasise: neither the repository pattern, nor command / query objects, are silver-bullets. Just because these architectural patterns exist, doesn’t mean you should use them in every single application. If your queries are simple enough (one or two lines), don’t worry about creating an abstraction over them. There is nothing wrong with writing them in your controllers (assuming a web application).
If you do, however, have fat queries that have bloated your controllers, you might want to consider one of these patterns to achieve “better separation of concerns”.
Repository vs Command / Query object
In a repository, we often have many methods, all related to a specific entity:
1
2
3
4
|
GetUpcomingGigs()
GetGigsIAmAttending()
GetMyGigs()
GetPopularGigs()
|
When you promote one of these methods to a class, you’ll end up with what we call a query object.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
|
public class GetPopularGigsQuery
{
private GigsContext _context;
public GetPopularGigsQuery(GigsContext context)
{
_context = context;
}
public IEnumerable<Gig> Execute()
{
return _context.Gigs
.Where(...)
.Include(...)
.Include(...)
.Include(...)
.OrderByDescending(...)
.Take(10)
.ToList();
}
}
|
So, what you see in the Execute() method here, used to be one of the methods of a class like GigsRepository. Now, we’ve promoted that to a class. Have we gained anything here? Absolutely not!
With this approach, if you have a repository with 5 methods, you’ll end up with 5 new classes in your application. Now, take into account how many repository classes you have and eventually how many command / query classes you’ll end up with. You’ll end up with an explosion of classes that don’t provide any additional value than a simple method.
When Command / Query objects provide value
When you want to execute some operation before and / or after the execution of the command / query. Sometimes, in large enterprise applications, you may want to check that the current user has permission to execute a given query (or command), and additionally you may want to log that somewhere.
Without using command / query classes, your repository methods would end up with a lot of duplicate logic:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
|
public IEnumerable<Gig> GetPopularGigs()
{
return _context.Gigs.......
}
public IEnumerable<Gig> GetUpcomingGigs()
{
return _context.Gigs.......
}
|
At this point, by promoting a method to a class, you’ll have at least a couple of options in front of you to implement the same behaviour in a more elegant way. You can use the template or strategy pattern.
With the template pattern, you would define a base class for your commands or queries like this:
01
02
03
04
05
06
07
08
09
10
11
12
13
|
public abstract class Query
{
public void Execute()
{
DoExecute();
}
abstract void DoExecute();
}
|
So, you write the authorization and logging logic only once, in the base Query or Command class. Then, when implementing an actual command or query, you override the DoExecute method:
1
2
3
4
5
6
7
|
public abstract class GetPopularGigsQuery : Query
{
public override DoExecute()
{
return _context.Gigs....
}
}
|
What about ASP.NET MVC action filters?
Mosh, aren’t action filters exactly for that? To execute some custom logic (e.g. like authorisation or logging) before each action? True! Then, why bother using the command / query pattern?
Good question! First, you don’t have to use the pattern, if you prefer to use ASP.NET MVC action filters. But what if, in the future, you decide to use a different web presentation framework that doesn’t have the concept of MVC filters? Tools and frameworks come and go. What is popular now, is not going to be popular in a few years time. There was a time we thought ASP.NET WebForms was so cool. Now, it’s almost a dead technology!
If you want to protect your application architecture from change of external tools and framework, you need to decouple it from them by creating your own abstractions. Command / query pattern is one of the ways to create such abstraction. If you switch over to a different presentation framework, you can take all your existing code and re-use it without modifying a single line, and more importantly, without breaking things along the way!
What if…
What if you’re not too concerned about decoupling your application architecture from external tools / libraries? What if you think this is overkill? That’s a perfectly valid argument. Then, don’t use these patterns. As I always say to my students: “Keep it simple”. Use MVC filters to achieve the same result, and if they won’t help you in the future, then you’d spend time solving that new problem, not now.
What if you don’t have such requirements like authorisation and logging before each query? Then, command / query objects don’t give you any additional value. You’ll just waste your time and energy writing more and more code.
What if you don’t have complex queries in the first place? Don’t bother with the repository pattern either!
Every pattern is designed to solve a specific problem. Don’t solve a problem that does not exist!
Till my next post, all the best my friends!
