The last year I have been working on a WPF frontend application that speaks to backend services through WCF. The WCF services were pretty standard request/response style services. For example:


The problem with this approach is that the services quickly got bloated. Some operations gut lumped into a MasterDataService which got pretty big. Another problem was that there was no real distinction between service operations that caused side effects (changed domain state) and read only operations.

Since then we have switched to a more simple service contract that looks like this:


Now all backend interactions go through this service. All operations in get to be their own command or query, so we get clear distinction between commands that modify state and queries that only read data and have no side effect. This interface requires that all commands inherit from the Command type and all queries inherit from the Query type. When you use inheritance in WCF you need to specify all subtypes using the KnownType attribute on the base type, for example:


This sucks, because this means that every time you add a new command you need to remember to add it as a known type to the base class. Fortunately the WCF team provides a way to provide known types at runtime by specify a static method:


The KnownTypesHelper will scan the contracts assembly for types inheriting from Command.

The implementation of the Backend service will lookup a command handler based on the type of command coming in. All command handlers implement the generic interface IHandleCommand<TCommand>. These command (and query) handlers are automatically registered in the inversion of control container. I really like the idea of having a separate handler for all service operations, it enforces the single responsibility principle in that each command handler only handles one command (compared to normal service implementations that might handler multiple operations). It also conforms to the open closed principle in that adding a new command and command handler requires no change to any other classes.

Example of a command handler:


One could ask why we did not use a message system like NServiceBus. The reason was that we figured that it would be an easier transition to move to a new WCF service contract than bring in a whole new framework. With this service in place it was really easy to rewrite operations (requests) into commands and operations that required a response to queries. Some operations that changed state AND returned data were split into a separate command and query (commands cannot return data).

Anyway, it has been working really well for us so try it out!


Sam said...

I'll second the recommendation to try out this style: I'm part way through work on migrating our WCF service layer to use a Command/Query/Handler approach and it's working really well for me.

Anonymous said...

Very nice idea, I like the idea of this command/query-style operations.

Have you ever looked at Davy Brion's request-response service layer?

Lorenzo Maiorfi said...

What about using WCF RIA Services?

osmirnov said...

Looks like Command and Query Responsibility Segregation (CQRS) pattern.

Torkel Ödegaard said...

I don't really like the RIA approach.

Benny Michielsen said...

You should take a look at Agatha.

Benny Michielsen said...

Offcourse I forgot the url:

Anonymous said...

It seems nice, but can you elaborate a bit more on what those Query objects and their results look like, as well as how do you handle failed commands (because of validation and/or business rules) and how does it look like to send and receive a query from the client and the server (handler) side?

Anonymous said...

It looks like sending a query would follow the same pattern as a command. One base object for your query request, one base object for your query return. It would look like

QueryResponse Query(QueryRequest)

Then you go on and start deriving and making the specific query classes. Validation/business rules failure could be handled via exceptions.

Anonymous said...

Funnily enough this pattern starts to look very much like HTTP:

Query -> GET
Command -> POST


I am implementing the same pattern. Essentially HTTP without using HTTP, but also allowing easy extensibility to pub sub semantics, new transport protocols ... not being constrained to HTTP


Anonymous said...

It's a nice introductory post to CQRS architectural pattern. For advanced scenarios, where you'd consider to use a distributed messaging system to communicate the different components of the system using different communications patters (Pub/Subs, Request/Response, ...). There are many implementations out there: nServiceBus, Rhino Service Bus, RabbitMQ, ... Hope it helps.

Anonymous said...

Excellent work. Thanks for sharing. I was looking for exactly same solution. Do you mind sharing the full implementation code?

Torkel Ödegaard said...

An implementation can be found here:

JeffM said...

Here's a similar command/query/handler implementation, but makes it so the client doesn't have to know which QueryResult subclass to downcast to for each Query.

Cindy Dy said...

This is a great article for my research. Keep posting. Thank you.