Code Contracts: Video on the static checker

Just a short hint for today: Francesco Logozzo from the Code Contracts team has made a little introductory video on the static checker. In this video he introduces the static checker and basically describes its fundamental algorithm: abstract interpretation.

Take a look at this video and please keep giving feedback to the Code Contracts team. Those are great guys who are very open for every suggestion!

Currently I’m making my mind up on DbC and the synergy with TDD and other paradigms again, so stay tuned for further blog posts on this topic.

Merry christmas to all of you!

Rx: Event composition – single-valued

In a first blog post on the topic „event composition with Rx“ I presented operators that take several event input streams and create a single output streams, whose elements contain values from each input event („multi-valued“ event composition operators). This second blog post instead treats “single-valued” event composition. Multiple streams go into those composition operators and one single stream comes out, where each element of the output stream matches exactly one event/value from any input stream!

Example solution, PPT slides and general information

In general, all introductory information on composition, description of the „multi-valued“ event composition operators and more bits-and-pieces can be found in my first blog post.

I’ve created a SL3 demo project where you can experiment with each composition operator. You can find the sourcecode (SL3 VS2008 project) here and the live demo on Windows Azure here.

The PPT slides that contain all diagrams of the composition operators can be downloaded here.
I would be glad if you could leave my name and/or the blog URL ( on every diagram.


The operator Merge does serialization of all input event streams by firing an event everytime one of the input streams fires. The event/value of the output stream will be the same as the event/value on the input stream that has fired.

The following code shows the simple usage of Merge:

    var composition = 
        Observable.Merge(stream1, stream2, stream3);

And the following example flow diagram shows the behavior of the operator under this code. Note how the incoming events are written to the output stream in exactly the same order as they come in:
Rx Event Composition - Merge


Amb comes from ambiguous and has the following semantics. If you combine several input event streams with Amb, the output stream will only contain the events from the input stream that fires first. The other input streams are not taken into account afterwards. That’s a kind of winner-takes-all-strategy and could be valuable in some situations.

Amb can be used as follows:

    var composition = 

And the following diagram shows an example composition situation. Note that stream 1 fires first and consequently Amb only forwards events from this stream:
Rx Event Composition - Amb


Concat does (the name says it all) concatenation of the input event streams. But wait: how can this work? In fact Concat only works when you have finite event streams! On infinite streams, Concat watches the very first stream forever and the other streams don’t come to their turn. Thus use Concat on finite event streams, when serialization of the input streams in the right order is crucial.

The following code shows the use of Concat on three finite input streams:

    var composition = 

And here’s the concatenation done by this code in an example situation (the square brackets illustrate finite streams):
Rx Event Composition - Concat


The operator name says it all: Until forwards events from an input stream to the output stream until an event on a second stream occurs.

The following code shows the usage:

    var composition = 

And the following diagram shows the behavior of Until on 2 streams based on this code:
Rx Event Composition - Until


Again the operator name speaks for itself: WaitUntil does not forward events from an input stream to an output stream until an event on a second stream occurs. From then on every event of the first input stream will be forwarded.

Here’s some code that shows how WaitUntil works:

    var composition = 

And the following diagram shows WaitUntil’s behavior based on this code in an example situation:

Rx Event Composition - WaitUntil

That’s it again. I hope you finde this information useful. As in the blog post on multi-valued event composition, I want to encourage you to give me active feedback and to improve the examples and descriptions of the composition operators above. Thanks!

kick it on

Rx: Event composition – multi-valued

In preparation of some presentation on the Reactive Extensions (Rx) last week I’ve investigated the composition methods for several event streams on the Observable class. What methods are existing and what are they doing? Let’s take a look…

This first blog post treats „multi-valued“ event composition in terms of multiple streams going in and one stream comes out, but each element of the output stream is composed by sub-elements from each input stream! There is a second blog post that treats „single-valued“ event composition as well.

Example solution

I’ve written a little SL3 application where you can discover the behavior of those composition operators. It builds on example code that first has been published by Paul Batum some months ago and extends his code with some more possibilities. I’ve hosted the SL3 on Windows Azure where you can test it directly:

Rx Composition Demo

You can download the sourcecode of the Visual Studio 2008 solution as well: [Event Composition Sourcecode (ZIP)]
All you need to run the solution is the latest Rx for SL3 build, Visual Studio 2008 and the Silverlight 3 SDK.

Powerpoint Sources

If you want to use my diagrams in your presentations or somewhere else, here is the source PPT file: [Rx Event Composition PPT]
I would be glad if you could leave my name and/or the blog URL ( on every diagram.

How to read the diagrams and code

The general visualization concept is taken from Eric Meijer’s PDC session about Rx. Thanks Eric for your great work!

Rx Event Composition - General Visualization

The visualization shows an Rx composing operator in the middle. On the left there are event input streams, on the right is the composed output stream. The order of the events on a timeline is from right to left: the most right event goes first into the operator and comes first out in composed form. This is visualized by the t1, t2, t3 and t1‚, t2‚, t3‚ points.

The sourcecode snippets below are kind of abstract. They only show how the operators are used. They are based on 3 streams stream1, stream2 and stream3. Those streams can be seen as general abstract event streams, no matter which datatype they’re really using.

Now let’s come to our multi-valued composition operators…


The SelectMany operator should be known from LINQ on IEnumerable or others and is reflected by the from keyword in LINQ queries as well. It projects a foreach loop or several cascaded foreach loops, if you execute multiple SelectMany calls after another. Thus the order in which SelectMany is executed is relevant!

The same is true for SelectMany on IObservable. Take the following code:

var composition = 
    from element1 in stream1
    from element2 in stream2
    from element3 in stream3
    select new[] { element1, element2, element3 };

This is equal to the following direct use of SelectMany:

var composition = 
        element1 => stream2.SelectMany(
        element2 => stream3.SelectMany(
        element3 => Observable.Return(new[] { element1, element2, element3 }))));

With this code an example composition scenario could be:

Rx Event Composition - SelectMany

Note that the event order is crucial. The first event on every input stream is in the right order, thus yielding to a first composed event. The second event on input stream 2 first fires when the third event on stream 3 is fired. The resulting event in this case contains the first event from stream 1, since it retains the right event order.


CombineLatest is a very useful operator. It fires everytime when one input stream fires. Then the corresponding output stream contains the latest values/events from each input stream.

Here’s the code how to use the operator:

var composition = 
        stream2, (element1, element2) => new[] { element1, element2 })
        stream3, (elements12, element3) => new[] { elements12[0], elements12[1], element3 }));

And an example composition follows:

Rx Event Composition - CombineLatest


In comparison to CombineLatest and others the Zip operator doesn’t use any results from an event stream multiple times. However it builds a queue of the events on every input stream. When every input stream queue contains at least one event, the Zip composition operator fires. Thus it synchronizes events, whereas every event on an input stream is waiting for an event on the other input streams.

The following code shows the usage of Zip():

var composition = 
        .Zip(stream2, (element1, element2) => new[] { element1, element2 })
        .Zip(stream3, (elements12, element3) => new[] { elements12[0], elements12[1], element3 });

And the following diagram shows an example composition. Note that no event is used twice in the output stream and compare this with CombineLatest and the other operators:

Rx Event Composition - Zip

Note that the last event on stream 3 has no „partner“ on the other streams and thus it doesn’t appear on the output stream in this example.

Also notice that Zip() is equal to Join() if used with a conjunction of all input event streams as parameter:

var composition = 
            .Then((element1, element2, element3) => new[] { element1, element2, element3 }));

Join() – 2 out of 3

The Join operator can be used in many cases and is very flexible. The method Join() can take several event compositions as parameters. Everytime one composition fires, the whole operator fires. That said, if you create a conjunction of all your event streams, then the composed output stream will be equal to Zip().

But Join gives you more power and flexibility. One example is a „2 out of 3“-situation. Imagine you have 3 input streams and want Join to fire everytime when 2 input streams contain an event. This can be done by passing Join the appropriate partial compositions as shown in the following code:

var composition = 
            .Then((element1, element2) => new[] { element1, element2 }),
            .Then((element1, element3) => new[] { element1, element3 }),
            .Then((element2, element3) => new[] { element2, element3 }));

This yields to the following resulting composition for example input streams:

Rx Event Composition - Join 2 out of 3

Again in this example, the last event on stream 3 has no partner and doesn’t appear on the output stream (due to an odd amount of events over all input event streams).


ForkJoin can be used if you want a composition to fire exactly once. When all input event streams contain at least one event/value, the ForkJoin operator fires with the first event on every stream. Afterwards it doesn’t react to any changes/event on the input streams again.

Here’s the code how ForkJoin can be used:

var composition = 
    Observable.ForkJoin(stream1, stream2, stream3);

And here’s the diagram of a composition example:

Rx Event Composition - ForkJoin

That’s it for now, guys. I hope it’s valuable for you. Since these are just my initial ideas on this topic, I’m reliant on your feedback. Together we could make all those descriptions even more useful.

kick it on

Rx: Bing Translate Example

In his Rx session at PDC09 Eric Meijer gave a nice example named Bing Translate. It was connecting to Bing via the Bing Web Service API and translated some term given by the user. It was quite interesting because Eric used the Reactive Framework for handling the translation and did some composition of the incoming results. He took just the first 2 translations and discarded the others. This didn’t make much sense, but it was ok for demonstration purposes. As followup Somasegar described the example in his blog.

But there was a lack of the whole sourcecode (btw: Eric Meijer posted it now on the Rx forum, but not as VS solution) and so I implemented it on my own with some modifications and now I want to share the whole Visual Studio solution with you.

Live demo

I’ve put my Bing Translate example as SL3 application on Windows Azure at, where you can directly test it:

Rx Bing Translate Example - Reactive Extensions - Reactive Framework

Sourcecode requirements

Since the Bing Translate example uses the Bing Web Service API, you need to get a free AppId here. Additional information on the Bing API can be found on the Bing Developer Center. When you’ve obtained your AppId, insert it into the BingService.cs file (field AppId of class BingService) of the sourcecode below. Now you should be able to run the solution.

What you furthermore need to open and run the solution:

  • Visual Studio 2008
  • Silverlight 3 SDK
  • Reactive Extensions for SL3 (latest release)

Now give me the code!

Ok, you want it, you get it 😉

[Visual Studio Solution for Silverlight 3 (ZIP)]

Notes on the code:

  • Contrary to Eric’s solution, mine will not synchronize the translation events when using the SetUpTranslationService() method in the MainPage.xaml.cs file. Use the SetUpTranslationServiceWithJoin() method if you want to have some synchronization. The main advantage of Rx is the composition of event streams, so this synchronization shows how simple things could be.
  • The code’s style is not expressing my real coding skills. Since this is just an example project, I did not make it stylish and bullet-proof.

That’s it! Have fun and please feel free to give me feedback.

kick it on

News on Rx (Reactive Extensions for .NET)

Rx Logo - Reactive Framework - Reactive Extensions for .NETAs written before the Reactive Extensions for .NET (Rx, aka „Reactive Framework“) have been published as pre-release on their own DevLabs-site. The Rx-team is asking for feedback from you as developers and will include improvements into timely released development packages, until they’ll ship the final pieces with .NET 4.0. Check out the MSDN forum to give your feedback or ask for support.

So what’s new in Rx compared to the early DLL from the Silverlight 3 toolkit sources?

In general, many improvements were made on the API and functionality: methods on the Observable class have been rearranged and extended to give you full flexibility in many use cases. One method that I really love is Throttle(). Imagine that you have a textbox and everytime the user makes an input (without pressing Return) a data source is queried for items that match this input in some way (e.g. filtering by name or something). Now you discover that you’ve got performance issues. The search is done as the user types the first character and that’s not what you want. You only want to react to user’s input if he isn’t typing anything for -let’s say- 1 second. Throttle() solves this for you by one method call, you do not need anything else or do something manually. That’s great! Try to develop this with common event-based programming and you know what I mean…

Then the Rx-team intends to converge the functionality of IEnumerable and IObservable. IObservable has much of the functionality of IEnumerable and LINQ operators make composing, filtering and transformation of event streams very simple and intuitive. And in the DevLabs-release of Rx the Rx-team is moving some functionality from IObservable (such as the Amb() method) to IEnumerable as well. If you need it or not: this is leveraging the dualism of both concepts for developers and makes both interfaces more intuitively usable.

Furthermore the ground base of Rx is now Px (or PFx), the Parallel Extensions for .NET that will be part of .NET 4.0 as well. For every concurrent operation Px is taken and does the whole work (by creating a Task<T>). As a side effect of supporting Rx for .NET 3.5 SP1, the Rx-team has back-ported Px from .NET 4.0 to .NET 3.5 SP1 and made it usable for this platform as well. Great job!

One thing very cool and worth to mention are Subjects as new components in Rx. Subjects implement the type ISubject<S,T> and are kind of hybrids between IObserver<S> and IObservable<T>. A Subject implements both IObservable and IObserver and can be seen as „channel“ or „transforming storage“. The channel behavior is that you can push values as input into the subject via the IObserver methods (OnNext(), OnCompleted() and OnError()) and that you can subscribe to the Subject via the IObservable.Subscribe() method to get the output from the Subject. The Subject itself can do some transformation with the values that are pushed into it, can store the values and is able to take responsibility of what happens if someone subscribes to it. Subjects act as storage as well. When values are flowing into the Subject it can store them (or only the last or some transformed value, …) and when someone subscribes it can return all stored values (or only the last etc.). That means that e.g. an asynchronous operation needs not to be executed multiple times when using Subjects. The return value is stored in the Subject and can be extracted everytime a client subsribes to the Subject (independent of the moment of the subscription).
Dependent on the intent of the Subject, Rx comes with several implementations that differ in their transformation and output behavior:

  • AsyncSubject<T>: This subject is used for asynchronous operations where only one value is expected as result. Thus the AsyncSubject remembers only the last value.
  • BehaviorSubject<T>: This subject always has a current value and fires everytime the value changes. Thus it’s kind of the INotifyPropertyChanged event.
  • EventSubject<T>: This subject corresponds to an event stream and thus will never invoke OnError() or OnCompleted().
  • ReplaySubject<T>: This subject is like a tape/video recorder. It records all events that are pushed into it and can be replayed. On replay it will return all events that have been recorded in exactly the same order and time interval in which they occurred.

Another really nice development is an Add-In for Visual Studio: Reactive Extensions Generator. It overcomes the problem that all types in the .NET Framework rely on .NET events and don’t offer methods or properties that return corresponding instances of IObservable. This tool allows you to choose an assembly and it generates extension methods for all .NET events that it finds on the components of the assembly. Those methods will return the Observable pendants for those events instead. Really impressing stuff and very timely! Single drawback: it can be used only with  Visual Studio 2010 and .NET 4.0.

So to sum up again: I think Rx is valuable in many situations. First it’s a better pattern for reactive programming that unifies asynchronous programming (that normally returns just one value) and event-based programming (that typically has an infinite event-stream) and second it’s very strong when you want to compose (+ filter and transform) several event streams and when you want to build up and react to very special and complex events. Stay tuned for more information and examples on that in upcoming blog posts.

kick it on

PDC09: Live Framework… news?

Live Mesh LogoAt the end of 2008 and at the beginning of 2009 I was really fascinated about the Live Services, Live Framework and Live Mesh. And I was so enthusiastic that I spread it around in some blog posts and one magazine article. I really liked the basic idea, the platform and (already in CTP state) the development tools. And I saw a huge potential in building social applications that can be synchronized, shared, run online or offline on many devices and last but not least are easily developed, by giving us as developers a platform that we can easily leverage and where we can concentrate on our business/application logic.

Then things became quiet at Microsoft and everybody was wondering about the future directions of the Live Framework…

On September 8th the Live Framework CTP was shutdown by Microsoft… rest in peace! This made me really angry. The developer pieces were great and fun to use. And now everything was over, nobody could write applications for the Live Framework any longer or even use their already existing code bases… I just thought: what happened to Microsoft to take this great platform offline and to carry this huge potential to grave?

When announcing the shutdown of the Live Framework CTP the guys at Microsoft said as well that they will make the Live Framework/Services part of Windows Live and that news on it will come on PDC09.

Now there was the PDC last week. But where was Live Mesh or the Live Framework? It was something so huge on the last PDC and there have been really impressive showcases, but this year’s PDC lacked information about it nearly completely. There was just one session (CL26) on the whole topic: Live Framework – Present and Future. But this session was disappointing as well. It seems that the Microsofties themselves don’t know what future direction the Live Framework will take. Two announcements were made, but only in a more-or-less inofficial fashion:

  1. Mesh technologies will be part of the next release of Windows Live.
  2. Mesh technologies will be fundamental for some Windows Live applications.

That’s it. The spirit to build a great platform has gone, at least I don’t feel anything left of it…
Just one demo has been shown, but this was disappointing as well: something like a Live Framework with synchronization capabilities, but everything is stored in folders and files on the filesystem and there seems to be no logical unit of data any more (besides those physical files/folders). What are you making there guys?

Mary-Jo Foley asked Ray Ozzie for Live Mesh at the PDC09. He said news on Live Mesh will be published at MIX 2010 respectively in spring 2010. Until then: I’m still very confused and sad about the current situation and developments on this topic at Microsoft. It seems that those guys haven’t understood the potential and once again they haven’t understood the community and the customer’s needs!

kick it on

Silverlight 4 Beta released!

Short announcement again. I really like watching PDC keynotes! Today tons of new features in Silverlight 4 have been presented and last but not least: you can download the Silverlight 4 Beta today!

An RC will follow and the Final will be released in the first half of 2010. Stay tuned!

Download and information:
What’s new:
SL4 Training Course:

Reactive Framework: it’s here!

Short announcement: Microsoft has published the Reactive Framework as Reactive Extensions for .NET (Rx) on its own DevLabs page (see release notes). Check it out now!

(Have you noticed the former Volta logo? ;-))

New Channel9 video are available, too: Rx in 15 minutes, Reactive Extensions intro, first Rx app).

And they’ve got a new Rx Team Blog.

I will give it a look at this weekend.

Reactive Framework (Rx) – first look

During the last weeks I took some time to have a first look at the Reactive Framework. Here I want to share some impressions and information with you.

Rx: What is it about?

The Reactive Framework (Rx) has been developed at the Microsoft Live Labs and is another creation by Erik Meijer, the father of LINQ. Rx will be part of the upcoming .NET Framework 4.0, but is already included as preview DLL (System.Reactive.dll) in the sources of the current Silverlight 3 Toolkit. It’s used there to get some smoother Unit Tests to work.

The aim of Rx is to simplify/unify complex event-based and asynchronous programming by providing a new programming model for those scenarios. That’s very important in a world which becomes more and more async (Web, AJAX, Silverlight, Azure/Cloud, concurrency, many-core, …) and where present approaches (event-based programming with .NET events, Begin/Invoke) hit the wall. Program logic gets hidden in a sea of callback methods which leads to nasty spaghetti code. Those of you who are creating larger async programs know what I mean 😉

Basic ideas

The main concept of Rx is reactive programming and that’s not new at all. It involves a distinction of data processing methods into push and pull scenarios:

  • In a pull-scenario your code/program is interactively asking for new data from the environment. In this case the actor is your program while it pulls new data from the environment.
  • In a push-scenario your program is reactive. The environment in pushing data into your program which has to react on every new incoming data item (see illustration below). Reactive programs are ubiquitous: every event-handler (e.g. for UI events) is an example for a reaction in a push-scenario.

Reactive Programming

The guys at Microsoft got a very important insight which builds the fundament of Rx: there’s a dualism between the Iterator and the Observer pattern! This means that both patterns are essentially the same, if you dismiss their practical intentions for a moment.
With the Iterator pattern you get a sequence of data which is iterated in the pull-mode: the Iterator is the actor and asks the iterable object for data.
The Observer pattern can be interpreted equivalently: the environment pushes data into your program (e.g. through events), which has to react. As result with repeatedly fired events you get a sequence of data, which makes the relationship to the Iterator pattern obvious.

With this, an Observer in the push-scenario is equal to an Iterator in the pull-scenario and that’s the key insight, which has led to the development of the Reactive Framework. 14 years had to pass from the publication of the GoF Design Patterns book until now to figure out this intense relationship of the Iterator and the Observer pattern.

LINQ to Events

Rx realizes the Observer pattern with the two interfaces IObserver and IObservable which are the pendants for IEnumerator/IEnumerable of the Iterator pattern. IObservable is a sort of „asynchronous collection“, which represents the occurrence of a certain event at different points in time. Thus it expresses a sequence of data, on which you can run arbitrary actions. In fact IObservable for push-scenarios is essentially the same as IEnumerable for pull-scenarios.

The interplay of IObservable and IObserver is the following: on an IObservable you can register (Subscribe()) an IObserver (Note the dualism to IEnumerable/IEnumerator here!). The IObserver has three methods OnNext(), OnCompleted() and OnError(). These methods are invoked when the IObservable gets new data, completes the data sequence or results in an error. Thus your IObserver implementations take care of the data processing which replaces your custom callback methods.

The real impressing thing with Rx is that with events as data sequences you can use LINQ syntax to process and transform these data sequences (that’s why it’s sometimes called LINQ to Events). To create instances of IObservable and for providing LINQ methods, Rx comes with the class Observable. If you want for example take the first 10 click events on a button but skip the first click, you could easily write:

Observable.FromEvent(button1, "Click")
    .Subscribe(ev => MyEventAction(ev));

Subscribe() has some overloads. In this example I’ve directly specified an action which is executed when an event (= a piece of data) comes in. Instead you could give it e.g. your custom implementations of IObserver as well.
LINQ gives you real power in processing, composing and transforming your events as data stream. Even in the simple example above, if you would implement it by event-based programming without Rx, you would need some additional effort. You would have to use temporary variables to skip certain elements, take others and so forth. In general, more complex cases require complete finite state machines which can be circumvented with Rx.

Composing events with LINQ is another typical and impressing example for Rx. Thus, a dragging event on a textblock can be implemented as:

IObservable<Event<MouseEventArgs>> draggingEvent =
    from mouseLeftDownEvent in Observable.FromEvent(textBlock1, "MouseLeftButtonDown")
    from mouseMoveEvent in Observable.FromEvent(textBlock1, "MouseMove")
        .Until(Observable.FromEvent(textBlock1, "MouseLeftButtonUp"))
    select mouseMoveEvent;

In this example, with the from keyword the two events "MouseLeftButtonDown" and "MouseMove" are chained together. Everytime the left mouse button is pressed on the textbox, the „gate“ opens to react on mouse move events. The „gate“ closes again when the left mouse button is released. So the composed stream includes all events where the left mouse button is pressed and the mouse is moved – the typical dragging event!

There are other possibilities to compose events, which for example consider the order of events differently. Those build the interesting parts of the Reactive Framework and clarify the use cases, where Rx has real advantages over present event-based .NET programming.

Bottom line

Personally I like the new way of thinking of events as data sequence! The dualism of the Iterator and the Observer pattern has nothing artificially constructed, but some sort of purity and mathematical elegance for me. But one big question remains: do we need this in our everyday’s developer life and which advantages come with it?

Erik Meijer himself says about Rx:

Of all the work I’ve done in my career so far, this is the most exciting. […] I know it’s a bold statement, but I really believe that the problem of asynchronous programming events has been solved.

That’s a really strong message and it has some important weight since Erik is the creator of LINQ and has a big expertise in language design. Does Rx hold what he promises?

In my opinion Rx is really beautiful and valuable when you do complex asynchronous operations, where you have to compose and orchestrate events/data from several sources. With Rx you’re able to chain and filter events to easily create the concrete event, to which you want to react. That’s the power of LINQ, which allows transforming the resulting data as well. LINQ gives you the whole flexibility of processing the data stream that you already know from LINQ to Objects (on IEnumerable) etc.

Beyond that at the moment I don’t see a real big impact in many current development scenarios. If you have to handle simple events or do simple async computations, you are still fine with the present event-based programming model. Of course with Rx you can write your own observers to prevent a sea of callback methods, but encapsulation of handler logic can be done without that as well. Thus at the end I like the concepts of Rx (Observer, LINQ, …) and I’m curious to see how this whole thing develops after the release of .NET 4.0, but I’m not over-enthusiastic at the moment.


Finally here is a list of links to some interesting websites regarding the Reactive Framework:

kick it on

Is the Specification Pattern obsolete?

I’m a guy who loves many of the new patterns that I get to know. But sometimes when I show that pattern to colleagues around me, they tilt their heads and say: „Arrrm, who needs this?“. Often they help me to get back to the ground and think again about intents and benefits of one or the other pattern.

Currently I’m rethinking the Specification Pattern, which has been introduced by Eric Evans and Martin Fowler some time ago and got some attention in the DDD community and beyond. The intent of the Specification Pattern is to separate the logic for (e.g.) filtering an entity from the entity itself. This responsibility is encapsulated in single classes – the specifications. Those specifications are given for example to a single method Filter() on a repository, which takes care of filtering the domain model by the specifications. Thus, you bypass the need for having several special methods in your repository which take care of the actual filter operation (such as FilterByCustomerName(), FilterByCustomerAddress() etc.).

An example interface snippet for a repository of persons with a specification filter method could then be:

interface IPersonRepository
    IEnumerable<Person> Filter(ISpecification<Person> filterTerm);
    // ...

Summarized, some key benefits of the Specification Pattern are:

  • Loose coupling of the filter logic from the objects being filtered,
  • Single responsibility: Interface of repository/data provider isn’t polluted with lots of filter methods,
  • Callers can express in a flexible way by which criteria entities can be filtered,
  • Composition of specifications (e.g. by a fluent interface) yields to flexible filter queries, for example:
    [sourcecode language=’c#‘]var filter = Filter.By(25).And(„Frankfurt“)[/sourcecode]

But now the provocative question that one could come with: Who needs the Specification Pattern in times of C# 3.0 and Expressions? This might sound disturbing at first, but let me explain…
C# 3.0 came up with the new concept of Expressions/Expression trees. This way, code can be treated as a kind of syntax tree in the program. Developers can extend the tree with additional code portions and then compile it into executable code which can be invoked.

Therefore Expressions seem to give us similar benefits for filtering as specifications do. By using Expressions, we are able to define a single Filter() method on the repository, which gets an appropriate Expression as argument. Consumers of the repository can call this method with their custom filter Expressions and thus we’ve got the same benefits: loose coupling of filter logic and objects to be filtered, flexibility for callers to provide custom filter criteria and the possibility to combine several filter criteria (several Expressions).
One could argue that with specifications we’ve got better encapsulation of the filter logic into separate classes. But this can be done with Expressions as well (e.g. by separate wrapper classes or dedicated Expression providers), so that isn’t a good argument…

The interface of a repository of persons with a filter that uses Expressions might look like this:

interface IPersonRepository
    IEnumerable<Person> Filter(Expression<Predicate<Person>> filterTerm);
    // ...

This leads again to the question: Do we still need the Specification Pattern or is it already embedded with Expressions in the language (C# 3.0) itself?

Pattern focus

First I want to mention that the intent of a pattern is not (only) to provide a technical solution, but also a conceptual guideline for a problem at hand. Thus Expressions as technical solution don’t cover the intent of the Specification Pattern. The Specification Pattern can be implemented with the help of Expressions, but that’s another point. So, directly comparing the Specification Pattern with Expressions is like an apple-pear-comparison.

Encapsulation focus

Let’s come to use cases when I would prefer the use of dedicated specification classes rather than directly using Expressions.
First as a team lead you could want to enforce the use of dedicated specification classes in your development team (thus enforce encapsulation of the filter logic). By giving Expressions or Predicates to filter methods directly,  developers would be allowed to define filter expressions whereever they want to. You don’t have the control over this process and please don’t trust your project guidelines: If developers are allowed to do something wrong, they will do.

With specifications you can force your team members to write specification classes for their requirements, which leads to enforced encapsulation. Furthermore you drive reuse of existing specification classes. Other developers are encouraged to use existing specifications, especially because of the additional effort for writing new specifications. By combining several specifications, the reusability aspect is pushed even more.

Domain model focus

Giving consumers the full flexibility of defining custom filter criteria with specifications can be very handsome in many situations. However, in other scenarios instead of giving full flexibility, you may want to restrict the set of filters for your domain model. If you focus on your domain, you perhaps want a restricted set of specifications, each with a very specific meaning in your domain! Binding such specifications to your domain model makes the purpose of your domain and how it can/should be used in terms of filtering much clearer.

Technically, in order to restrict access to a particular set of specifications, you could create sealed specification classes inside of your domain model services (same layer as repository). Consumers of the repository would be allowed to call the Filter() method on the repository with those specifications (and compositions of those), but they would not be able to create new specifications if you don’t mark the specification interface as public. This way you get two characteristics: Restricted filtering, which fits into your domain and your use cases on the one hand, and encapsulation/separation of filter logic and entities which should be filtered on the other hand.

Bottom line

This article started with an interesting and provocative question: Is the Specification Pattern obsolete? This question came up with a look at Expressions in C# 3.0. Technically you can achieve similar results when using Expressions instead of implementing the Specification classes by hand. But as the last sections have shown, in my opinion the Specification Pattern is not obsolete! As pattern it’s adding very specific value to the plain technical solution, when you take encapsulation and domains into account. Then it clearly goes beyond the technical aspect which many developers see at first sight.

Those are my current thoughts on specifications, but of course my opinions are not carved in stone. What do you think? What points I’ve missed perhaps? I’m eager for your comments!

kick it on