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!

Yesterday I held a talk at a cornerstone event titled Pimp My Code at Hard Rock Café in Göteborg. The talk was about convention over configuration. I began by quickly describing the design philosophy and it's origins (in for example ruby on rails) and after that it was all code demo.

The code demo was a walkthrough of an application I had written (with some bits requiring live coding) that showcased a bunch of conventions. The application uses a lot of frameworks, for example Fluent NHibernate, StructureMap and AutoMapper. My point was not to dig deep into these frameworks but show show how they provide support for conventions and how that can be utilized in your application architecture. Among other things I showed how a Command/Query WCF service with automatic handler lookup could be achieved.

The frontend part of the application was taken from Rob Eisenberg MVVM mix talk. I modified it a bit and connected it to a real backend system. This application is treasure trove of brilliant ideas. Ideas that later materialized in the excellent Caliburn Micro framework.


I will be doing the same presentation in Stockholm on december 6th at Debaser Medis. It is fully booked, so for those that have managed to get tickets, see you there!