1. Updated Validation library for WPF/Silverlight. A long time ago I wrote an article on WPF Validation, including a custom ErrorProvider. There are a number of issues and limitations with the inbuilt WPF validation, even in the latest incarnation of the framework, and so I’ve updated the ErrorProvider control and done significant performance tuning to really take it to the next level. Features include error summaries, hints, support for many validation sources (IDataErrorInfo, Validation Application Block, your own system via a plugin), and control over when validation takes place (automatic, explicit, or only when a control has had focus). I just have to document it and publish it somewhere.
2. A WPF/Silverlight SiteMap library. I tried to capture many common features of site map systems, like support for dynamic/static site maps and changes to the site map structure (via Bindable LINQ, of course :-)) but I would probably approach this as more of a CodeProject guide rather than a CodePlex library.
3. Next version of Bindable LINQ. I’ve been working on the documentation here for a while and making a few improvements here and there, and I’d like to get it to a "1.0" status and freeze the API a little better.
4. WPF/Silverlight Forms library. A library of useful abstractions over common tasks such as building input forms. Code is written, just need to publish it and build some samples.

I’m thinking of combining them all (except Bindable LINQ, of course) into one Codeplex library.

Which of these would you like to see first? And are you interested in helping to get them over the line?

This step-by-step guide will walk you through setting up your first project using Bindable LINQ.

Scenario

In this walkthrough you will create a new Windows Presentation Foundation project which uses Bindable LINQ to filter an array of strings as a user types.

Requirements

Bindable LINQ is compatible with the .NET Framework version 3.5 and above. To follow this guide, you will need to install Microsoft Visual Studio 2008 Standard edition, or you can install the free editions of Microsoft Visual C#/VB.NET 2008 Express.

Steps

1. Download Bindable LINQ
   You can either download the latest stable release from the Codeplex releases page, or download the latest source code and build it yourself. To compile the project yourself, read the section "Building Bindable LINQ".
2. Create a new WPF Application project
   Using any edition of Visual Studio 2008 which supports WPF, create a new WPF Application project using either C# or VB.NET.
   
3. Add a reference to Bindable LINQ
   Extract the downloaded archive of Bindable LINQ to a folder of your choosing, or if you built it yourself, locate the build outputs folder (see the Building Bindable LINQ page for details). From Visual Studio, select Add Reference…
   
   From the Browse tab, navigate to the Bindable LINQ directory and add a reference to Bindable.LINQ.dll. This is the only reference you will need.
   
4. Build the GUI
   You will need a ListBox to show the list of names, and a TextBox to filter them.
   

   <DockPanel>
       <TextBox x:Name="_textBox1" DockPanel.Dock="Top" />
       <ListBox x:Name="_listBox1" />
   </DockPanel>

5. Add a using directive for the core Bindable LINQ namespace

   In order to use Bindable LINQ, you will need to add a "using" entry for the Bindable.Linq namespace:

   using Bindable.Linq;

6. Initialize a list of names and write the query 

   Create an array of first names, and then use a Bindable LINQ query to filter and order them.

   public Window1()
   {
       InitializeComponent();
   
       var names = new [] { "Paul", "Michael", "Sally", "Sally", "Mary" };
       _listBox1.ItemsSource = from n in names.AsBindable()
                               where n.StartsWith(
                                   _textBox1.Text,
                                   StringComparison.CurrentCultureIgnoreCase
                                   )
                               orderby n
                               select n;
   }

7. Run!

   The application should compile and run at this point. As you type in the TextBox, Bindable LINQ will detect changes to the TextBox (since you called it from your "where" query), and will re-evaluate the items in the collection.

It’s that easy. To see the experience of using standard LINQ to Objects, remove the "AsBindable" call and run the query again.

To see more ways to use Bindable LINQ, see the Examples, Sample Applications, or Bindable LINQ Patterns pages.

What some people (mostly people on the CLR and C# language team) forget, is that there are alternatives to console applications. Here’s the typical User Experience of an F# program:

There’s only one thing that’s constant in our world: change. Inputs change, assumptions change. So why is everyone so enthralled with a programming paradigm that has such abysmal support for handling change?

Your highly concurrent, lambda powered, currying pattern-matching data analysis algorithm, running over 87 threads and 8 cores, is a pretty good effort. But once it’s analysed the 3,000,000 visits to your web site and told you what products to put on discount, what happens to the 3,000,001′th visitor? Well, once your functional code arrived at a result, it kinda forgot how it got there. So you have to run the whole thing again for a minor change in the inputs.

Wouldn’t it be great if you could write code in a functional programming language, but which automatically detected changes and re-evaluated itself? A kind of event stream processor. As visits come in your algorithm is being constantly evaluated, quickly, and the results updated. It’s the difference between being able to react in real-time, and having to wait for the hourly report to be generated.

As it turns out, there’s a paradigm for that: it’s called functional reactive programming. And unlike normal functional programming, it actually has uses outside of console applications

F# developers go gaga over pattern matching:

let getWarningMessageAboutTooManyToppings toppings =
  match toppings with
  | 0 -> "You didn't select any toppings"
  | 1 -> "You should have more toppings"
  | _ when toppings < 5 -> "That's a healthy number of toppings"
  | _ -> "Too many toppings on your pizza, fatboy" 

Now that’s great, but what happens when I select a new topping? I guess that’s what "Refresh" buttons are for.

Here’s a functional reactive version of pattern matching, supported via Bindable LINQ’s Switch operator (you’ll find this in the PizzaLinq sample application in the Bindable LINQ code).

_healthWarningMessage = _selectedToppings.Count().Switch(
    Case.When<int, string>(toppings => toppings < 1,
        "Surely you would like more toppings?"
        ),
    Case.When<int, string>(toppings => toppings >= 3,
        "You have too many toppings!"
        ),
    Case.Default<int, string>(
        "Just right!"
        )
    );

In Bindable LINQ, when I select a topping on the UI the result of the Count() call will change, which will re-evaluate the Switch operator and return me a different message. There’s no Refresh buttons and no code to wire it up. It’s functional, but it’s also useful.

If you could get enough programmers working on a reactive .NET language, it’s conceivable that you could combine the implicit parallelism of functional languages with reactive languages in order to process changes and have a result that’s continually updated from multiple threads. Unfortunately, all the smart developers are focused right now on a paradigm that’s severely limited to back-end or discreet, point-in-time operations, rather than a more wide-ranging paradigm like that of functional reactive programming.

If you’re a language wonk and you’re considering learning F# and functional programming for fun, consider reactive programming instead.

Below is the "Bindable LINQ/Background" page, which describes what Bindable LINQ is. What do you think?

Overview

Bindable LINQ bridges the object-oriented world of .NET, and the paradigm of reactive programming. While the procedural, object oriented or functional programming paradigms focus on discreet evaluation of code, the reactive programming paradigm instead focuses on continuous evaluation, and propagation of change. Bindable LINQ leverages the syntax of LINQ and the platform support of Data Binding to enable advanced scenarios that would otherwise require reams of code.

Bindable LINQ is not a library for querying databases or web services. For more information on where Bindable LINQ fits into your application architecture, see the section on Bindable LINQ patterns.

Reactive Programming

To understand the difference between discreet and continuous evaluation, consider the following C# code:

decimal total = 0;
IList<LineItem> lineItems = ...;
foreach (var item in lineItems)
{
    total += item.Quantity * item.Price;
}

The value of the total is derived from the lineItems collection. But in this case, once the foreach loop has completed and the total variable assigned, this relationship is lost. If the lineItems collection, from which the total was derived from, changes, the total will not change. You can think think of this code as representing a "point-in-time" snapshot of the total.

In a reactive programming language, the relationship between the source - lineItems - and the destination - total - should be maintained at all times, and changes to the source should be propagated.

Bindable LINQ allows you to use the familiar syntax of LINQ queries in a reactive programming way. For example, the order totaling code above could be written in Bindable LINQ as:

ObservableCollection<LineItem> lineItems = ...;
IBindable<decimal> total = lineItems.AsBindable().Sum(li => li.Quantity * li.Price);

LINQ

LINQ to Objects is an implementation of LINQ that ships with the .NET Framework and allows querying over in-memory collections such as generic Lists or Arrays. However, once the query has been evaluated and the results have been yielded, subsequent changes to the source collection are not propagated. LINQ to Objects is a purely discreet evaluation and assignment construct.

Bindable LINQ follows the same rules as other LINQ providers and works in-memory, just like LINQ to Objects, except the relationship to the source collection is changed. When the source collection raises events indicating that something has changed, Bindable LINQ will propagate the changes throughout the LINQ query, evaluate the changes, and any derived values will be updated.

Data Binding

Data Binding is a UI platform technology that allows properties of UI controls to be synchronized with properties of objects. To facilitate propagation of change, these objects can implement a number of interfaces, primarily INotifyPropertyChanged, IBindingList and INotifyCollectionChanged.

Bindable LINQ queries implement these data binding interfaces so that UI controls can be connected and kept in-sync with Bindable LINQ queries automatically. This leverages the platform’s support for data binding, while removing the limitation of data binding patterns as a UI-control level only concept.

Summary

Bindable LINQ leverages the familiar syntax of LINQ and the platform’s support for data binding to bring reactive programming to the .NET Framework. You express what you need, and Bindable LINQ takes care of wiring up event handlers, detecting changes and the complexities of propagating those changes.

Joseph Cooney launched a community project last week to create a repository of useful pixel shader effects for WPF. It’s already got a number of effects, including a very cool radial blur effect. Rather than just blogging a link, I wanted to contribute to the library and build a shader that I’ve been thinking about for a while.

Twelve percent of Australian men, and 0.5% of women have some degree of colour vision deficiency, which makes up a significant segment of the audience for many applications. To aid in testing, the ColorBlindnessEffect allows you to simulate how your WPF application will look under various classifications of colour vision deficiencies. Here are some images of Joseph’s sample application running with Normal, Protanopia (loss in the red-yellow-green spectrum) and Tritanopia (loss in the blue-yellow spectrum):

The effect provides eight filters:

1. Protanopia
2. Protanomaly
3. Deuteranopia
4. Deuteranomaly
5. Tritanopia
6. Tritanomaly
7. Archromatopsia
8. Archromatomaly

You can learn more about colour blindness on Wikipedia.

What I liked most about this commit is that the code was reduced. Before the changes, the Bindable LINQ solution was 20,829 lines of code; now it is down to 18,882 lines. Needless to say, this has led to a few breaking changes, and some of the tests don’t pass (yet), but it seems to work

Threading: Before

When I originally thought up Bindable LINQ, I had the idea of an Asynchronous operation. The idea was that you could setup a query over another data source, and Bindable LINQ would simply return an empty collection, then kick off a background thread, and as items are yielded, they’d be added to the Bindable LINQ result set and the UI automatically updated. I described it in my first video here:

The Asynchronous operation could also be applied last, so other Bindable LINQ operations could be done as part of the background thread. This meant that every Bindable LINQ class had to be aware of multiple threads.

Threading has it’s tricks, but it isn’t that hard. After some early trial and error and plenty of time debugging deadlocks, I settled on some key principals:

1. Never hold a lock while calling code you didn’t write
   It might try to take a lock, while another thread holds that lock but wants to call your code. Deadlock.
   • This includes when raising events
   • This includes iterating over external items. I took snapshots of any external collection passed into Bindable LINQ, unless it was already a List<T>.
2. Take snapshots of IEnumerables.
   I explained this in my post Snapshot Enumerators, which I still believe is the correct approach in the multi-thread aware scenario. You just can’t rely on Window 1 not to be looping through your collection while the user is clicking "Delete" in Window 2 (assuming they used different threads).
3. Use locks when doing stuff to edit the collection
   Of course, since editing is meant to raise events, I created a "Transaction" system whereby only one thread could be performing a transaction at once, and once released, any events from changes made would be raised. It was complicated, but fun

As you can imagine, these principals caused a lot of overhead in the code, but I was absolutely convinced the multi-threading support was worth the cost. Then I changed my mind

The reason for my backflip came when, having used Bindable LINQ in a couple of projects, I realised that in all asynchronous related scenarios, the Asynchronous operator didn’t go far enough, or didn’t let me take all of the advantages of threading (it couldn’t use PLINQ, for example).

Instead, I found myself just doing a regular Bindable LINQ query over an ObservableCollection<T> which was empty, and managing the background tasks myself, and using the Dispatcher to route the new items to the ObservableCollection<T>. It was actually a simpler approach, and I realised the Asynchronous iterator wasn’t that useful.

Threading: After

Like WPF UI elements, Bindable LINQ queries are now bound to a Dispatcher. If updates come from source collections on the wrong thread, they’ll be routed to the right thread before processing. Most operations in Bindable LINQ, such as GetEnumerator() or Refresh(), require that they are called on the dispatcher thread. It might sound like a limitation, compared to the previous approach, but it made all of the queries a lot easier.

What this meant is I was able to cut out some of the problematic areas:

1. All that code to avoid locks while making external code
   Many methods went from dozens of lines to two or three.
2. Snapshots
   Since only one thread can be enumerating the collection at any one time, snapshots just aren’t needed.
3. Locking
   When you ensure the object can only be touched from one thread, you generally don’t need to lock.

I think this can best be summed up by "YAGNI".

Dispatchers and Testing

A brief aside, but some issues can come up when combining the use of Dispatchers with unit tests. Here’s how I approach them in Bindable LINQ.

As I’m sure you know, components like the Background Worker or the Dispatcher work by sending messages from the current (background) thread to the message queue of the owning UI thread, which pulls them off the queue (just like a Button Click message) and processes them. This works great when you have a UI running, but not so great when you don’t, because there’s no message queue to read the messages from.

As a solution to this, I create the following components:

• IDispatcher, an interface with methods like:
  • bool DispatchRequired();
  • void Dispatch(Action action);
  • void Dispatch<TResult>(Func<TResult> function);
• WpfDispatcher, which adapts the WPF Dispatcher object to the IDispatcher interface.
• SilverlightDispatcher, same as above, except for Silverlight. Since Silverlight doesn’t support synchronous invokes (you have to use BeginInvoke), I create a AutoResetEvent, and set it after the action has been processed, to effectively enable synchronous invokes.
• TestDispatcher, which provides a simulator for the dispatcher.

It might sound like the simulated dispatcher is tricky, but in reality it turned out to be pretty simple. Instead of dispatching onto an owning thread, I just create a new thread each time - easy!

Suppose thread "A" is your UI thread, and thread "B" is your background thread. Here’s how it would work with a normal WPF dispatcher:

1. Your UI is running on thread A
2. You dispatch an operation from thread B
3. It puts a message in the message queue for thread A
4. Thread B waits (if it’s a synchronous Invoke) or continues (if it’s an asynchronous BeginInvoke)
5. Thread A picks it up and processes it

In your tests, there are usually a couple of things you want to do:

• Test that the thing you’re doing in the background is actually called on thread B
• Test that any events you are raising are getting called on your foreground thread

So, our Test Dispatcher enables this:

1. Your test is running on thread A
2. You dispatch an operation from thread B
3. It creates a new thread, and calls the operation on the new thread (thread C)
4. Thread B waits (if it’s a synchronous Invoke) or continues (if it’s an asynchronous BeginInvoke)
5. Thread C does the action.
6. You test that the action happened on thread C

Since your tests won’t know about Thread C, the IDispatcher manages this. Recall that IDispatcher supports a DispatchRequired method, which returns true if it is called on a thread which is not the UI thread.

In our test dispatcher, we pretend that each of the subsequent threads we create (thread C, thread D, thread E), is also the owner thread. So in DispatchRequired, we check for the owner thread (A), or any of the threads we’ve used as fake Dispatcher threads. Pretty easy

That’s my general approach to testing multi-threaded components that rely on a dispatcher of some description. If you’d like to see the code, here’s some direct links:

• IDispatcher.cs
• SilverlightDispatcher.cs
• WpfDispatcher.cs
• TestDispatcher.cs

Let me know what you think. To get the count of lines of code, I use a little utility I wrote some time ago here. Tomorrow night I’ll blog about some other changes I made in the name of simplification, as well as the new Switch operator

Central to this is the theory that the items higher up the pyramid tend to get thrown out when the lower ones are under threat.

The Composite WPF project ships with a reference implementation that demonstrates how to apply the Composite WPF libraries. By contrast, Expression Blend is a good example of how to apply composite WPF techniques to a specific problem, without using any of the libraries. For this reason, I thought it would be interesting to compare the two.

Disclaimer: I draw all conclusions about the Expression Blend code from Reflector alone and inferring what the components do, rather than actually having read any documentation on the topic. I may be completely wrong in some aspects

Expression Framework overview

Expression Blend has a few assemblies, the most interesting one being the Microsoft.Expression.Framework DLL. This provides the foundation classes that the various Expression products use in their architecture. The top-level Expression Framework design is decoupled, like Composite WPF applications, but it has also been simplified in interesting ways.

To implement an Add-In, you implement an IAddIn interface, and you are given access to an IApplicationService object. This service provides a set of application-level properties, for example:

• AddInService : IAddInService, which lets you register more Add-Ins into the Application
• CommandBarService : ICommandBarService, which give the ability to register commands on the toolbar
• Packages : IPackageCollection, which contains all of the "packages" (modules) loaded into the application. Examples are a Code Editing package, a Design Surface package, etc.
• ViewService : IViewService, for opening and closing views.
• MessageDisplayService : IMessageDisplayService, for message boxes and dialogs
• MessageLoggingService : IMessageLoggingService, for writing to the output window

What this leads to is a hierarchy of logical components that make up any Expression application:

• An Expression Application (IApplicationService) is made up of:
  • Application-level services like menus, logging, messaging and scheduling
  • Add-Ins (implementing IAddIn)
  • Packages (IPackage) for specific bits of functionality, which tend to get their own DLL’s, such as:
    • CodePackage, which allows for editing code, by providing:
      • CodeEditor, which is a control for editing source code
      • CodeViews, which host the editor and implements IView
      • CodeDocument, which represents a source file being edited
    • DesignerPackage, which allows for designing documents
    • ProjectPackage, for support for various Visual Studio project types

Now let’s look at some of those components, and consider how they would be approached in Composite WPF.

Composition: Modules vs. Packages

In contrast to monolithic applications, composite applications are about allowing distinct areas of functionality to be implemented separately, and then be "composed" together into an application. Composite WPF is based around modules, which are conceptually the equivalent to Packages in Expression Framework. When a Composite WPF application starts up, all Modules are located, and are told to initialise. A Composite WPF module is given an IUnityContainer, which it uses to register and consume services that can be used in other modules in the application.

public class NewsModule : IModule
{
    private IUnityContainer _container;

    public NewsModule(IUnityContainer container)
    {
        _container = container;
    }

    protected void RegisterViewsAndServices()
    {
        _container.RegisterType<INewsFeedService, NewsFeedService>(new ContainerControlledLifetimeManager());
        _container.RegisterType<INewsController, NewsController>(new ContainerControlledLifetimeManager());
        _container.RegisterType<IArticleView, ArticleView>();
        _container.RegisterType<IArticlePresentationModel, ArticlePresentationModel>();
        _container.RegisterType<INewsReaderView, NewsReader>();
        _container.RegisterType<INewsReaderPresenter, NewsReaderPresenter>();
    }

    public void Initialize()
    {
        RegisterViewsAndServices();

        INewsController controller = _container.Resolve<INewsController>();
        controller.Run();
    }
}

In the Stock Trader reference implementation, each module gets it’s own assembly, but it’s also possible to put many modules in one assembly, or to use many assemblies to compose and decouple a single module.

In the Expression Framework, modules are known as Packages. A Package provide a distinct area of functionality to an Expression application, like code editing or designer features. Each one tends to live in its own DLL. Here’s what an Expression Package looks like:

public sealed class CodePackage : IPackage
{
    public CodePackage();
    public void Load(IApplicationService applicationService);
    public void Unload();
}

The IApplicationService provides a set of properties that indicate what application-level services are available, and the Package can use them to access all of the areas of functionality it needs when it loads up. Conceptually, it acts like the IUnityContainer used in the Composite WPF reference implementation.

Key takeaway: The Package API makes it clear that a Package is clearly loaded into the context of an application. A Composite WPF module is just loaded into something. The Expression approach seems to lend itself well to exploration - "I’ll write a package that shows a message box. What’s this IApplicationService… oh, the MessageDisplayService property - that sounds like it could be what I want".

In the Composite WPF reference implementation, using just the IUnityContainer, you have to already know which services are available - it’s not so obvious. I think it would be nice to wrap the IUnityContainer as an IApplicationService, and expose application-level services as properties, and still use the container internally. There’s nothing in Composite WPF that would prevent that.

Key takeaway: As a semantic thing, I like the choice of name for a "package", because it is domain-specific. If I was building an insurance modelling application, which was made up of a lot of different modelling suites, even using Composite WPF, I’d consider renaming IModule to IModellingPackage. Names tell you a lot about what something is and help relate the product you’re building to the implementation.

Dependencies and Services: IUnityContainer vs. IApplicationService

In Composite WPF, when a module is created, it registers all of the services it provides into the IOC container, and they are available to other modules. It’s a nice, generic solution, and it leads to a lot of consistency.

The rules in the Expression Framework are fairly similar. The IApplicationService implements IServiceProvider and provides AddService() and GetService() methods, and so functions similarly to an IOC container, albeit with a lot less features. When a Package loads, it can ask the IApplicationService for a service provided by another module.

What both solutions appear to be missing is good support for cyclic dependencies. When a module is registered, you specify the other modules it relies on, and Composite WPF makes sure to load them in the correct order according to their dependencies.

protected override IModuleEnumerator GetModuleEnumerator()
{
    return new StaticModuleEnumerator()
        .AddModule(typeof(NewsModule))
        .AddModule(typeof(MarketModule))
        .AddModule(typeof(WatchModule), "MarketModule")
        .AddModule(typeof(PositionModule), "MarketModule", "NewsModule");
}

When a module is initialised, it registers all of its services and then resolves any objects that rely on other modules, all in the one call. As the modules are loaded, it would happen in this order:

1. News module registers all services
2. News module creates and shows some views
3. Market module registers all services (it has no views)
4. Watch module registers all services
5. Watch module creates some views (using services provided by Market)
6. Position module registers all services
7. Position module creates some views (using services provided by Watch and Market)

Because each module is loaded in turn, you’ll get exceptions if you have cyclic dependencies between modules, which might be limiting.

Instead, I like to use a two-phase initialisation process, which would make each module look like this:

public class NewsModule : IModule
{
    private IUnityContainer _container;

    public NewsModule(IUnityContainer container)
    {
        _container = container;
    }

    protected override void RegisterSharedServicesOverride()
    {
        base.RegisterSharedServicesOverride();

        _container.RegisterType<INewsFeedService, NewsFeedService>(new ContainerControlledLifetimeManager());
        _container.RegisterType<INewsController, NewsController>(new ContainerControlledLifetimeManager());
        _container.RegisterType<IArticleView, ArticleView>();
        _container.RegisterType<IArticlePresentationModel, ArticlePresentationModel>();
        _container.RegisterType<INewsReaderView, NewsReader>();
        _container.RegisterType<INewsReaderPresenter, NewsReaderPresenter>();
    }

    protected override void ConsumeSharedServicesOverride()
    {
        base.ConsumeSharedServicesOverride();

        INewsController controller = _container.Resolve<INewsController>();
        controller.Run();
    }
}

And would thus be run the following order:

1. Phase 1: Register Shared Services
   1. News module registers all service
   2. Market module registers all service
   3. Watch module registers all services
   4. Position module registers all services
2. Phase 2: Consume Shared Services
   1. Watch module creates some views (using services provided by Market)
   2. Position module creates some views (using services provided by Watch and Market)
   3. News module creates and shows some views

This allows modules to have cyclic dependencies (though of course, not cyclic DLL references, so you’d have to split the interfaces out into satellite or shared assemblies), since all modules get a chance to register before they consume.

Key takeaway: It’s interesting that the Expression team chose not to use an IOC container, and instead use not much more than a Hashable. That said, I would still choose a full IOC container like Castle Windsor any day. I do however like the way application-level services (as opposed to module specific services) are exposed much more clearly.

Key takeaway: Cyclic dependencies between modules may not come up, and there often are workarounds, but if you do, this is probably an area you’ll have to make a few tweaks to.

UI Composition: Regions vs. Views

In Composite WPF, when you want to show something on screen, you can ask the IOC container for an IRegionManager. The region manager provides a set of named IRegions, which you can get a reference to, and add UI elements to them.

IRegionManager regionManager = Container.Resolve<IRegionManager>();
IRegion detailsRegion = regionManager.Regions["DetailsRegion"];
detailsRegion.Add(view);

Regions are quite generic. Panels on a form can be regions, as can toolbars and menus. The library comes with a set of adapters that allow specific WPF UI elements to act as regions - out of the box adapters include ItemsControlRegionAdapter (for a region with multiple controls) and ContentControlRegionAdapter (for regions with only one view). If you want to adapt to other, more complicated elements, you can write your own adapter pretty easily.

In Expression, the IApplicationService is a little more specific about what "regions" are available. You can get a CommandBar service, ViewService (for views on the main window), or WindowService (for popping up new Windows), each of which have a specific API according to what they are doing.

Here’s how adding a command to the Expression CommandBar would look (I gather, from the API). As you can see, it’s more explicit about which options are available:

var commandBar = applicationService.CommandBarService.CommandBars["CommandBarName"];
var button = commandBar.Items.AddButton("MyButton");

Key takeaway: I think the Region model is a nice idea, but perhaps a bit too limiting. The assumption is that all Regions just contain a list of Views, and should all conform to the same API, makes it a bit more clunky to code against and isn’t as intuitive as the Expression Framework approach. I like that the Expression Framework defines specific API’s for the various types of views.

The Expression Framework approach to regions is certainly possible to do using Composite WPF, and there’s no reason you can’t mix the models - using Regions for most panel-like regions, and more specific interfaces for menus or command bars. Expression shows that it is possible to be more specific while still being loosely coupled. 

Eventing: Services vs. Event Aggregator

The final thing I was interested in is how services in modules communicate with each other, primarily around reacting to events.

In Composite WPF, services in a module can consume other services from other modules by getting them from the IOC container. Those services could then expose events, which the dependent modules/controllers could subscribe to. 

The Expression Framework works this way as well. When packages load, they can resolve services from the IApplicationService, and subscribe to events (such as the ActiveViewChanged event on the IViewService). I like this approach to eventing because it is consistent with all other forms of collaboration between services in modules.

However, Composite WPF also provides an alternative model. Instead of subscribing to events on individual services, you can obtain a reference to an IEventAggregator from the IOC container. You can then setup a subscription to the event, and events can be published from anywhere, with the IEventAggregator acting as a messaging hub. The IEventAggregator approach has a few noteworthy advantages:

• Event subscriptions are weak references by default. This is hugely important, because in the alternative approach outlined above, you need to make sure to unsubscribe from any events when the view is unloaded or else the service will keep your view alive indefinitely.
• You can pass a ThreadOption to tell the event aggregator which thread to call you back on, such as always on the UI thread, or always on a background thread.
• Multiple publishers can publish an event. In the first approach, only the service can raise the event, and you’d have to build your own layer to allow notifications from many places.

I am actually in two minds about this. On the one hand, the advantages of the event aggregator approach are hard to ignore. However, if I’m going to call methods on services in a different module one way, I’d like to subscribe to events in much the same way. The Event Aggregator is a bit of an anomaly considering the rest of the guidance is so focused on IOC.

Key takeaway: I would prefer to approach eventing as I would approach any other collaboration service, using the IOC container. I think the benefits of the Event Aggregator, including automatic threading and weak referencing, could be done nicely using Castle Windsor Interceptors instead.

Conclusions

My interest in this comparison was to see how the Expression Framework approached certain problems which Composite WPF provides an alternative approach for. Since my first review on Composite WPF (then "Prism"), I’ve been a big fan, and I’ve recommended it as a base for a number of client engagements. But as I wrote in my first review, I think these projects should always be used as guidance, not gospel, and not as DLL’s you blindly reference and patterns you blindly follow. Expression Blend shows that there are many ways to skin a modular cat, and that rolling your own isn’t such a bad idea.

Something this reinforced is that it’s common to see architects on a team that spend all of their time evaluating patterns and frameworks. It is like an orchestra conductor who spends all his time evaluating which instruments the musicians should play, and not conducting the music. The result is a group where everyone is playing to a different tune, because there’s no shared vision of what they’re playing.

The Expression Framework enables loosely coupled, modular, composite applications, without strictly following all of the patterns or tools we spend so much time arguing about. It demonstrates how important it is to have a clear, cohesive vision of what you’re actually building, and how unimportant specific tools and libraries are. I get the feeling that someone on that team has a very clear vision of what they’re producing; a conductor that focuses on the music and not the instruments. Those are the architects I’d like to work with.

Windows Forms has a nice designer that let’s us drag and drop controls on the form, spend a bit of time with the margins and alignments, positioning stuff, and compiling it. It allows you to get something functional quite quickly. It’s where the "RAD" myth started.

However, Expression Blend supports nearly all of those features. We get snapping and alignment and all the other goodies:

Resources

So in terms of raw "banging out a UI" ability, there’s not much difference. But using WPF enables a lot of extra options. For example, the Windows Vista user experience guidelines give us some standards that we should follow when it comes to margins between controls:

• Margin between related controls: 7px
• Margin between unrelated controls: 11px

Using WPF we can translate that into a pair of resources:

<Application.Resources>
    <Thickness x:Key="Layout_StandardMarginBetweenRelatedControls">0,3.5,0,3.5</Thickness>
    <Thickness x:Key="Layout_StandardMarginBetweenUnrelatedControls">0,7.5,0,3.5</Thickness>
</Application.Resources>

If I have a bunch of controls, the "StandardMarginBetweenControls" will put a 3.5px margin around each one, or 7 between two controls. If I need to break up the list with a control that is not related, I apply the "StandardMarginBetweenUnrelatedControls" to the next control, which will put 3.5 + 7.5 = 11 between the two controls.

Using these resources from Blend couldn’t be easier. I select my group of related controls, and apply the resource to the Margin property:

If we now change our mind, we can update the resource from the one place, and it will apply to every place we’ve used it. We’re able to leverage our investment in resources later to make the application faster to maintain. By contrast, if I decide to change my Windows Forms layout, I need to manually fix each Form, since reusing something as simple as a margin in Windows Forms is actually quite difficult. 

Here’s some other useful things you can turn into styles or resources:

• The font settings to apply to all labels
• The standard margin around the border of the Window
• The standard width and height of buttons
• The standard horizontal alignment of labels (left-aligned labels versus right-aligned labels - Vista UX guidelines say Left)

And those are the simple ones. We can take this leveraging power further by abstracting the problem we’re trying to solve.

Abstraction

Let’s think about what a Form is. Your typical Form window has a header, body, and footer with some buttons. The body contains a set of Fields, which have a label, an optional description, and one or more editable controls. We can take these concepts and turn them into some simple stub classes that we can style up.

First, I built some classes to represent the object model of an input form. After I stubbed out the classes, here’s what the markup looked like:

<Forms:Form Style="{DynamicResource Form_SimpleFormStyle}">
    <Forms:FormHeader
        Icon="ResourcesImagesUserNew32x32.png"
        Title="Create an account"
        />

    <Forms:FormFooter>
        <Forms:FormButtonBar>
            <Button Content="Save"/>
            <Button Content="Cancel"/>
        </Forms:FormButtonBar>
    </Forms:FormFooter>

    <Forms:FormBody>
        <Forms:FormField Header="First name:" IsRequired="True">
            <TextBox Text="" TextWrapping="Wrap" Width="300"/>
        </Forms:FormField>
        <Forms:FormField Header="Last name:" IsRequired="True">
            <TextBox Text="" TextWrapping="Wrap" Width="300"/>
        </Forms:FormField>
        <Forms:FormField Header="Email address:" Description="Your email address will not be shared with anyone." IsRequired="True">
            <TextBox Text="" TextWrapping="Wrap" Width="300"/>
        </Forms:FormField>

        <!-- Continued -->
    </Forms:FormBody>
</Forms:Form>

The intent was to capture what a form "is", and separate it from what it "looks like". I spent 10 minutes defining some very simple styles and templates to lay out the contents of each object, and then switched back to define the half-dozen forms I was building:

Then I put on my designer hat. Since I’d pushed all of the layout information into the styles and templates, I was able to alter the look of all of the forms quite heavily without actually changing any of them:

In total, the resource dictionary for the complete set of styles came out to 271 lines of XAML - most of which was done in the designer using Blend. I even put some design-time specific styles in to make the design experience nicer:

The time consuming part was creating the classes and styles. But with them in place, building a single dialog is more productive than in Windows Forms, since I don’t have to think about layout at all. It’s all about leverage.

In summary:

• The WPF + Blend solution allows your design team to design the form layout separately to the implementation of the specific form.
• The WPF + Blend solution allows you to enforce consistency by taking layout concerns away from the developer and giving them to the designer.
• By abstracting the layout markup to add more structure, we make the markup and design experience for the controls much simpler.
• By using WPF’s leveraging capabilities - styles, resources, templates, and most importantly, separating form from function - we are more productive in the long term.

This is the stuff Windows Forms is meant to be superior at. We haven’t even looked at WPF’s extra features, like Commands, Navigation, or the far superior Binding. The only downside is the learning curve.

I’ll be posting these resource dictionaries and controls sometime soon as part of a wider library of assets for rapid WPF development. In the mean time if you’re interested in seeing the markup, drop me an email (paul@paulstovell.com).