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:

image

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:

image

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:

image

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:

image

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:

image

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!

8 comments:

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: http://code.google.com/p/agatha-rrsl/

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?