Queries with Mediator and Command Patterns

Queries with Mediator and Command PatternsI recently got a really great comment from my post on using Query Objects instead of Repositories.  Although that blog post is now 2 years old, I still use the same concepts today in my applications.

What I thought may be relevant is to elaborate more on why and when I use the mediator and command pattern for the query side.

It may seem obvious on the command side, but not really needed on the query side.

Here a portion of the comment from Chris:

I’m struggling a bit to see the killer reason for using Query objects over repository. I can see the benefits of CQS but it’s this command pattern type implementation of the Q part I struggle with. I can see for Commands (mutators) the benefits of having separate handlers as you can use decorator pattern to wrap them with additional functionality e.g. Transaction, Audit etc.

However for queries I’m struggling to see why you wouldn’t just use a normal repository. Essentially your IQuery object defined what would be a method signature in the repository and the handler defines the implementation of the method. However at some point you have to compose the IQuery class to it’s handler either using a dependency injection framework or Mediator pattern as in your following blog.

Query Objects

The primary place I use query objects (mediator + command pattern) is when I want to be decoupled from an integration boundary.  Often times this is between my application and the web framework I’m using.

I view my query objects as my public API.

Which means I usually want to create a pipeline for those queries.  I will use a request pipeline for handling things such as authorization, validation and logging in the query pipeline.

Since this is the same implementation I use on the command side, it’s easy to use with library like MediatR which handles both commands and queries as a “Request”.


I still use repositories, but just very differently than I did before.  Since my query objects are my public API, my repositories are generally only used internally within a the core of a given application (or bounded context).

My repositories are usually pretty narrow and also handle things like caching.


There are many ways to implement the separation between reads and rights.  I’ve failed at making this point clear in many of my prior posts.

I’ve had a few encounters recently that make me feel like there’s still a lot of misconceptions about what people think CQRS is.  I’ll keep posting quote from Greg Young.

CQRS is simply the creation of two objects where there was previously only one.

The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation, a command is any method that mutates state and a query is any method that returns a value).

That’s all it is folks.  Not really that interesting.  What’s interesting are all the possibilities because of this simple idea.

How you implement that is up to you.

One of the ways I’ve been implementing this is with the Mediator + Command Patterns.  It’s not the only way!


How are you implementing the query side?  Always enjoy hear your feedback, commands and questions.  Please let me know on twitter or in the comments.


Environment Variables in ASP.NET Core

In my last post, I covered how to handle sensitive configuration data by using User Secrets while working in development or on your local machine.  The next step is how to use environment variables in ASP.NET Core once you deploy to production (eg Azure App Service)?


In your ASP.NET Core Startup class, the ctor has a IHostingEnvironment parameter.  One of the properties on it is the EnvironmentName.  Along with this are a few extension methods such as IsDevelopment(), IsStaging(), IsProduction().

In the sample below, you can see if the environment is development, then I’m adding the User Secrets to the ConfigurationBuilder.

What IHostingEnvironent.IsDevelopment() ultimately does is checks to see if the IHostingEnvironment.EnvironmentName is equals to Development.


How did IHostingEnvironment.EnvironmentName get set to Development?

If you are using Visual Studio you can access this in the in the project properties.

If you are outside of Visual Studio, you can manage it by editing the launchSettings.json.  This is what a sample looks like.

Environment Variables

You can also add additional environment variables that will be loaded when ConfigurationBuilder.AddEnvironmentVariables() is called in Startup.

In my above example, only under development are user secrets loaded.  This is done after environemnt variables are loaded.  This means that the user secrets override any environment variables I’ve set.

Azure AppService

Once you are ready to deploy to azure, you may want to set your environment as well as other environment variables that you need which will be used instead of user secrets.  You can do this in your App Service under Application Settings.




Always enjoy hear your feedback.  Please let me know on twitter or in the comments.


Sensitive Configuration Data in ASP.NET Core

While working on my new side-project in ASP.NET Core, I was at the point where I needed to start storing sensitive configuration data.

Things like my DocumentDB Auth Key, Google OAuth ClientId & Secret, Twilio Auth Token, etc.

Depending on your context you may not want to be storing these types of application settings in configuration files that are committed to source control.

As you would expect, my local environment for development and once I deploy to Azure have completely different configurations.

So how do you change the configuration from local to production?

If you are used to using appSettings from the app.config and web.config, you may have been going down the road of transforming and replacing values with tools like SlowCheetah or through Octopus Deploy.

With ASP.NET Configurations, there’s a new way to do this.


ASP.NET Core has a ConfigurationBuilder that enables you to load application settings from various places.  If you’ve loaded up a brand new ASP.NET Core app, you’re Startup looks something like this.

You have a new appsettings.json file you can use as well as an optional appsettings for each different environment.

I could use the appsettings.Development.json for local development, however as mentioned i want to keep sensitive data out of this file.

For this, I’ve now been using User Secrets.

User Secrets

ASP.NET Core adds a new way to store your sensitive data with User Secrets.

User Secrets are simply a plain text json file that are stored in your systems user profile directory.  Meaning the file is stored outside of your project directory.

There are a couple ways to manage your user secrets, first you need to add Microsoft.Extensions.SecretManager.Tools in the tools section of your project.json.

I’m unaware of how this translates to the new .csproj format.

If you are using the dotnet CLI, then you should now be able to run dotnet user-secrets --version

Next in your project.json you want to add a “userSecretsId” property in the root.  The value can be anything you want but should probably keep it unique so it doesn’t collide with another user secrets you create for any other project.

In order to load the secrets file, you need to first add Microsoft.Extensions.Configuration.UserSecrets package in your project.json

As mentioned, since I only use user secrets for local development, we can now load the secrets using the ConfigurationBuilder in our Startup

Visual Studio

If you are using Visual Studio, you can edit your user secrets file by accessing it in the context menu of your project in the solution explorer.


If you are using the dotnet CLI then you can call dotnet user-secrets [options] [command] to clear, list, remove and set secrets.


Simple example would be wanting to store the connection string to a database.

 dotnet user-secrets set ConnStr "User ID=Derek;Password=CodeOpinion;"

Now within our code we can access the connection string after we built our configuration from the ConfigurationBuilder.


Next post I’ll take a look at how you can use Environment Variables and specifically how to set them when deploying as an App Service within Azure.

Always enjoy hear your feedback.  Please let me know on twitter or in the comments.