It is not uncommon when when writing tests that you want check that the correct items with correct data exists in a list. You can do this in many ways, most of which I have found to be problematic at times.

Example:

image

This approach forces the item order to be the one you expect. This can be overcome by sorting the list before. Another approach that I do not like, but have seen a lot:

image

This approach do not care about the order of the items, but will not generate instructive errors. When the test fails you get no hint of which property was wrong, was there any items in the list, was it the project number or the quantity that caused the mismatch?

I have been working on a reporting story that denormalized a big document into a single class with a large number of properties. This required a number of tests that checked the items and their generated properties. However I wanted a nice syntax and good instructive test errors that explain what property caused the mismatch and what alternative values that property was found with.

I set out to create this in a generic way to be reusable in other tests. And ended up with this:

image

Lets say there only exists an item with project number 123 and placement “Front”, and maybe 10 rows with other project numbers, then the fist line would throw a test fail like this:

image

The important point here is that not only do I get what property caused the mismatch but also the alternative values for that value given the project number filter of 123 (that is I do not get all values for the mismatched property). 

This becomes useful when you have many properties and multiple rows you want to check. Because all filters that results in hits will be applied, and all that give no hits will not be used, so you can present an error that includes the mismatches, but also found alternative values for the mismatched properties. I am not sure if I am making any sense. 

Maybe the filter logic will help, CollectionTestHelper:

image

I try to filter the list using the property function and value, if no hits are found I revert to the “unfiltered” list and add the property expression and value to a dictionary. I then revert to the “unfiltered” list, which is a bad term as it is the list with all matching filters applied.

The complete code for the CollectionTestHelper look at this gist: https://gist.github.com/1509663

In one case I made a helper method in the test class that has 14 optional parameters, so I can get this syntax:

Example:

image

Optional parameters are great for making tests and setups clearer.

What i like about command query segregation is that it allows you to clearly distinguish between operations that modify states (via persisting aggregates) and queries that only read. Reads require very little business logic or behavior so why do many system still handle reads the same way (architecturally speaking) as writes? Why do reads need to pass through a domain repository, a domain entity and (god forbid a domain “manager” class), then only to get mapped to a DTO and later a view model?

Realizing the big difference between reads and writes has been the biggest change in mindset for me the last year. When you realize this you can create different architectures and layering for reads and for writes.

For example queries can be handled like this:

image

The above query handler needs to return product details and the order count in which that product exists. No behavior, no business rules, no domain entities or aggregates needed, just data that needs to be returned to later be displayed in a GUI. So no repository needed! So how do you test the query handler? The same way you would test the repository method, using a database test (preferably in-memory).

If you read a whole aggregate in a query handler something is most likely wrong, aggregates should only be read if you need to perform a command (modify it’s state).

Separating between read models and write models makes a huge difference. Write models will be modeled using domain driven design, aggregate roots should correspond to transactional boundaries. Aggregates should not require a change just because we need to display more data in the GUI.  I have seen domain entities filled with relationships and properties only there because some part of the GUI requires it.

If you use your domain aggregates when reading and displaying data it can lead to a huge amount of unnecessary data in the aggregate, data that is never used by the business rules but is still being read from the database on every write operation.

There is an interesting consequence in event sourcing, in that it allows you to create a domain model state that only contains state (data) that is necessary for the behavior, if you have data that is only required for reads then you can ignore that data in your aggregate (it will be stored in the event store, and in the read model).

I am only a novice when it comes to Event Sourcing and CQRS but I find both incredibly interesting. I like how they both create pretty big limitations that force you toward something good, and it makes you think more are about domain driven design, about boundaries and responsibilities and about intent. I would love to get the chance to try event sourcing and pure CQRS (separate read/write model and persistence) in a real project.

For more on CQRS:

Interesting, there is apparently no way to remove posts from google reader cache (even when the post is deleted from site/rss feed). Google reader will never ever remove deleted posts from its cache.

Good to know when you accidentally post to the wrong blog :) If that happens it is better to change the content of the post than delete it, then google reader will at least update it’s cache with the new content.

For more info:

http://superuser.com/questions/56908/remove-deleted-posts-from-central-google-reader-cache

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!

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.

Links

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!

An another interesting aspect about Rob Eisenberg MVVM sample application is how it handles binding solely through conventions. That is no binding expressions in the XAML and no event hookups in the code behind. This is accomplished through a class named ViewModelBinder. This class takes a view model instance and a view instance. For each public property on the view model it will try to find a corresponding control with that name in the view, if found it will define the binding expression in code.

A simplified version of the method that handles the property bindings:

private static void BindProperties(FrameworkElement view, IEnumerable<PropertyInfo> properties)
{
    foreach (var property in properties)
    {
        var foundControl = view.FindName(property.Name) as DependencyObject;
        if(foundControl == null)
            continue;

        DependencyProperty boundProperty;

        if(!_boundProperties.TryGetValue(foundControl.GetType(), out boundProperty))
            continue;
        if(((FrameworkElement)foundControl).GetBindingExpression(boundProperty) != null)
            continue;

        var binding = new Binding(property.Name)
        {
            Mode = property.CanWrite ? BindingMode.TwoWay : BindingMode.OneWay,            
        };
        
        BindingOperations.SetBinding(foundControl, boundProperty, binding);        
    }
}

When a control matching a property is found it will lookup in a dictionary the DependencyProperty that the view model property should be bound to. For example for a TextBox control it will bind to the TextBox.TextProperty. In the complete version of this method (please check the sample app) it handles hookup of bool properties to a Border control's visibility property, automatically configuring a BoolToVisibility converter on the binding. An important part of the method is where it checks if any manual (in the XAML) binding exists, if it already exists it skips the property/control. This allows you to override the conventions with manual bindings in edge cases.

There is a similar method that handles binding of public methods to commands:

private static void BindCommands(object viewModel, FrameworkElement view, IEnumerable<MethodInfo> methods, IEnumerable<PropertyInfo> properties)
{
    foreach(var method in methods)
    {
        var foundControl = view.FindName(method.Name);
        if(foundControl == null)
            continue;

        var foundProperty = properties
            .FirstOrDefault(x => x.Name == "Can" + method.Name);

        var command = new ReflectiveCommand(viewModel, method, foundProperty);
        TrySetCommand(foundControl, command);
    }
}

If a method with the same name as control is found it will create a new ReflectiveCommand and define the command binding. For example a method named ExecuteSearch matches the name of a button in the view. It will also look for a property that begins with Can and ends with the method name (for example CanExecuteSearch), if this property is found it will be used to determine if the command can be raised (which will disable and enable the button for example). Raising a property change for this CanExecuteSearch property will result in the ReflectiveCommand raising the CanExecuteChanged (defined on the ICommand WPF interface). This is pretty great, now all that boring command setup will be handled by infrastructure code! I am in the process of trying to incorporate some of these ideas into parts of a system I currently working on. The conventions defined in the Robs sample app will only get you so far, the nice thing is that it is now very easy to add new ones. The scenario I was working on today was how to hookup a DoubleClick event on a grid item to a method on the view model. If the convention based binding could look for a method ending with "_OpenGridItem" it could then check for the first part of the method, try to find a control matching that first part and hookup the DoubleClickEvent and then call the view model method. First we need to refactor the BindCommands method into something more extendible.

Fist we need an interface:

public interface IMethodBindingConvetion
{
    void Apply(object viewModel, FrameworkElement view, MethodInfo method, IEnumerable<PropertyInfo> properties);
}

Now we can move the already existing convention into it's own class:

public class CommandToMethodBindingConvention : IMethodBindingConvetion
{
    public void Apply(object viewModel, FrameworkElement view, MethodInfo method, IEnumerable<PropertyInfo> properties)
    {
        var foundControl = view.FindName(method.Name);
        if (foundControl == null)
            return;

        var foundProperty = properties
            .FirstOrDefault(x => x.Name == "Can" + method.Name);

        var command = new ReflectiveCommand(viewModel, method, foundProperty);
        TrySetCommand(foundControl, command);
    }
    
    //...
}

Now lets try to create the convention that captures DoubleClick on a infragistic Grid and calls the corresponding OpenGridItem method on the view model.

public class DoubleClickGridToMethodConvention : IMethodBindingConvetion
{
    public void Apply(object viewModel, FrameworkElement view, MethodInfo method, IEnumerable<PropertyInfo> properties)
    {
        if (!method.Name.EndsWith("_OpenItem"))
            return;

        var gridName = method.Name.Replace("_OpenItem", "");
        var gridControl = view.FindName(gridName) as XamDataGrid;
        
        if (gridControl == null)
            throw new ConventionBindingException("Could not find matching control for the method " + method.Name);

        gridControl.MouseDoubleClick += (sender, e) =>
        {
            var item = FindClickedItem(sender, e);

            method.Invoke(viewModel, new object[] {item});
        };
    }  
}

If you want the method to be able to return IEnumerable<IResult>, something I talked about in yesterdays post (async programming using coroutines), then you need to handle the return value of the method invocation and pipe that through a ResultEnumerator.

Now that we have delegated the method conventions to specific classes the BindCommands method now looks like this:

private static readonly IList<IMethodBindingConvetion> _methodBindingConventions =
            new List<IMethodBindingConvetion>()
                {
                    new CommandToMethodBindingConvention(),
                    new DoubleClickGridToMethodConvention()

                };

private static void BindCommands(object viewModel, FrameworkElement view, IEnumerable<MethodInfo> methods, IEnumerable<PropertyInfo> properties)
{
    foreach(var method in methods)
    {
        foreach (var methodBindingConvention in _methodBindingConventions)
            methodBindingConvention.Apply(viewModel, view, method, properties);
    }
}

This method should perhaps be renamed to BindMethods. Anyway the point of this post was really to show how the convention based binding ideas in Robs sample application can be expanded to fit the application you are building.

If you work with WPF or Silverlight then you really should check out Rob Eisenberg presentation at MIX10 titled Build Your Own MVVM Framework. In that presentation he goes through a sample application that utilizes no code behind and no data binding or command binding expressions, all is hooked up through conventions and is driven solely from the presentation model. The sample app has about 500 lines of framework or infrastructure code that handles the view look up and convention based binding. I urge you to download it and really dig through it, it contains some awesome code and ideas.

But I will focus this blog post on one aspect of that sample app which is how Rob implemented async workflows. It might be a long post with a lot of code :)

Sequential async workflow:

public IEnumerable<IResult> ExecuteSearch()
{
        var search = new SearchGames
        {
                SearchText = SearchText
        }.AsResult();

        yield return Show.Busy();
        yield return search;

        var resultCount = search.Response.Count();

        if (resultCount == 0)
                SearchResults = _noResults.WithTitle(SearchText);
        else 
                SearchResults = _results.With(search.Response);

        yield return Show.NotBusy();
}

Before I dig into what the above code does and how it works I need to explain the problem. Anyone who has worked with WinForms/WPF/Silverlight knows that backend calls and other long running work needs to be done on a background thread. However all UI updates needs to be done on the UI thread. If you use ThreadPool.QueueUserWorkItem and you want to notify the UI that something has updated (issue a NotifyPropertyChanged for example) then you need to marshal the the call via the WPF dispatcher so the NotifyPropertyChanged happens on the UI thread. Another option is to use the BackgroundWorker that automatically executes the event RunWorkerCompleted on the same thread that called RunWorkerAsync.

Example:

private void ExecuteSearch()
{
      IsBusy = true;

        var worker = new BackgroundWorker();
        
        IEnumerable<SearchResult> results;
        
        worker.DoWork += (e, sender) =>
        {
                results = searchService.SearchGames(SearchText);
        };
        
        worker.RunWorkerCompleted += (e, sender) =>
        {
                if (results.Count == 0)
                        SearchResults = _noResults.WithTitle(SearchText);
                else 
                        SearchResults = _results.With(results);
                        
                IsBusy = false;        
        };

        worker.RunWorkerAsync();
}

This does not look so bad, we still have all the code in one method thanks to the lambdas. But imagine that we need to fetch the game (another backend call) and open the game screen if the returned search result only match exactly one game. In that case we would need to new up another BackgroundWorker inside the RunWorkerCompleted lambda and then hookup DoWork and RunWorkerCompleted. The code would be very messy (nested lambda callbacks) and it would be hard to read the sequential flow of the process.

Coroutines to the rescue. Wikipedia definition reads:

Coroutines are program components that generalize subroutines to allow multiple entry points for suspending and resuming execution at certain locations
But C# does not have that! Well it kind of does. You can get the same effect if you define an enumerator using yield returns. In a method that returns IEnumerable you can use yield return. The C# compiler will turn that method into a state machine (to implement the enumerator). Each time someone calls MoveNext (which happens once each foreach loop) the execution of the method will continue until the next yield return.

Example:

public IEnumerable<string> GetStrings()
{
    yield return "Hello";
    
    Console.WriteLine("execution continued");
    
    yield return "Good bye";
    
    Console.WriteLine("Nothing left");
}

This method will be turned into a MoveNext method on a generated class that implements IEnumerator:

private bool MoveNext()
{
    switch (this.<>1__state)
    {
        case 0:
            this.<>1__state = -1;
            this.<>2__current = "Hello";
            this.<>1__state = 1;
            return true;

        case 1:
            this.<>1__state = -1;
            Console.WriteLine("execution continued");
            this.<>2__current = "Good bye";
            this.<>1__state = 2;
            return true;

        case 2:
            this.<>1__state = -1;
            Console.WriteLine("Nothing left");
            break;
    }
    return false;
}

Ok, so now that we know how yield works we can use that to get something like Coroutines.

public IEnumerable<IResult> ExecuteSearch()
{
   // yield returns...
}

public interface IResult
{
   void Execute(); 
   event EventHandler Completed;
} 

Back to Robs sample app. The ExecuteSearch method above returns an IEnumerable of IResult, an interface that has an Execute method and a Completed event. The magic happens in how this enumerable is consumed, which is handled by the ResultEnumerator class:

public class ResultEnumerator
{
        private readonly IEnumerator<IResult> _enumerator;

        public ResultEnumerator(IEnumerable<IResult> children)
        {
                _enumerator = children.GetEnumerator();
        }

        public void Enumerate()
        {
                ChildCompleted(null, EventArgs.Empty);
        }

        private void ChildCompleted(object sender, EventArgs args)
        {
                var previous = sender as IResult;

                if(previous != null)
                        previous.Completed -= ChildCompleted;

                if(!_enumerator.MoveNext())
                        return;

                var next = _enumerator.Current;
                next.Completed += ChildCompleted;
                next.Execute();
        }
}

This class might take some time to get your head around. What happens is that we take the first IResult by calling MoveNext, we then hook up the Completed event and then call the Execute method. The interesting thing is that the Completed event is hooked up the the same method that we are in. The result is that the first IResult controls when the next IResult is fetched (the next IResult won't be fetched until the one before executes the Completed event). Ok, think about this until you understand it :)

Now lets look at how we can use this. Lets try to create a IResult that executes a lambda in a background thread then executes the Completed event on the UI thread.

public class BackgroundResult : IResult
{
        private readonly Action action;

        public BackgroundResult(Action action)
        {
                this.action = action;
        }

        public void Execute()
        {
                var backgroundWorker = new BackgroundWorker();
                backgroundWorker.DoWork += (e, sender) => action();
                backgroundWorker.RunWorkerCompleted += (e, sender) => Completed(this, EventArgs.Empty);
                backgroundWorker.RunWorkerAsync();
        }

        public event EventHandler Completed = delegate { };
}

Lets look at our example that used BackgroundWorker but rewrite it to use our new BackgroundResult:

private IEnumerable<IResult> ExecuteSearch()
{
    IsBusy = true;
    
    IEnumerable<SearchResult> results;

    yield return new BackgroundResult(() => 
    {
        results = searchService.Search(SearchText);
    });
    
    if (results.Count == 0)
       SearchResults = _noResults.WithTitle(SearchText);
    else 
       SearchResults = _results.With(results);
                
    IsBusy = false;            
}

Looks better doesn't it? The BackgroundResult will block the execution of the method until the action completes which will fire the Completed event (which happens on the UI thread) which in turn will resume the execution of the ExecuteSearch method. The requirement to show the game screen when there is only one match is now much easier to handle as we can yield another BackgroundResult to fetch the game. The method logic happens in the sequential order that it is written, making it much easier to read, test and debug.

Now to the complete version of the method from Robs example app:

public IEnumerable<IResult> ExecuteSearch()
{
        var search = new SearchGames
        {
                SearchText = SearchText
        }.AsResult();

        yield return Show.Busy();
        yield return search;

        var resultCount = search.Response.Count();

        if (resultCount == 0)
                SearchResults = _noResults.WithTitle(SearchText);
        else if (resultCount == 1 && search.Response.First().Title == SearchText)
        {
                var getGame = new GetGame
                {
                        Id = search.Response.First().Id
                }.AsResult();

                yield return getGame;
                yield return Show.Screen<ExploreGameViewModel>()
                        .Configured(x => x.WithGame(getGame.Response));
        }
        else SearchResults = _results.With(search.Response);

        yield return Show.NotBusy();
}

In the complete version he handles the case where there is only one match, in that case GetGame query is also issued to the backend. Before I end this post I will just highlight another interesting aspect of this sample and that is how Rob handles backend interaction. Instead of directly calling a IBackend service he returns an IQueryResult or ICommandResult which will handle the execution of the backend call and the thread marshalling. This improves the testability as the method will not require any mocking to test.

It's not trivial stuff, it takes some time to get your head around how the ResultEnumerator works and what it makes possible. But I think it is a pretty brilliant solution to keep complex async workflows in the same place and be able to read them sequentially. I am not sure if it is the same thing but if I remember correctly I think the C# team is looking at making this easier in C# 5 with an async keyword. Does anyone know how this implementation of coroutines compares to the async features in F#?

Check out the full sample application