So long, and thanks for all the chips

Background Task in WPF

Thu, 04 Sep 2008 16:16:31 GMT

Writing multi-threaded code is hard. Very hard. Writing multi-threaded UI code is even harder. Much harder. See, user interface components are generally not thread safe. You can't modify properties or call methods on user interface components safely, unless you're in the same thread on which the component was created. This has been true on every UI framework I've ever dealt with, and it's true in WPF. This makes it very difficult to create multi-threaded UI code, because you have to constantly be marshalling operations across thread boundaries, which is both more complicated to code, and leads to the potential for race conditions and deadlocks.

WPF has helped to make the marshalling of operations across thread boundaries a little easier with the DispatcherObject class. DispatcherObject is generally used as a base class for other types, and all of the WPF UI components derive from DispatcherObject. When a DispatcherObject is constructed, it associates itself with the currently running thread. A couple of methods, CheckAccess and VerifyAccess, allow you to determine if the current thread is the same thread that the DispatcherObject was created on. CheckAccess simply returns a boolean, while VerifyAccess will throw an exception if the current thread isn't the associated thread on which the DispatcherObject was created. By convention, any property or method that must be called only when running on the associated thread will call VerifyAccess internally, thus ensuring they can't be called except from the thread on which the DispatcherObject was created.

So, we understand how DispatcherObject ensures that operations occur only on the associated thread. How does it help us to marshal operations onto this thread? DispatcherObject has a Dispatcher property that includes various overloads of Invoke and BeginInvoke that marshal operations onto the DispatcherObject's associated thread. All of this greatly simplifies the coding required to create objects with thread affinity and to marshal operations across thread boundaries. You should be aware that this isn't a silver bullet solution. The marshalling can still lead to deadlock. The general idea behind marshalling operations across thread boundaries is to bundle up the operation and put it in a queue where the other thread can extract it and run the operation. This requires the other thread to actually participate by checking the queue and running the operation. If that thread is busy doing something else, it won't be checking the queue and the operation will be sitting there. So, if one thread is marshalling to another, and that thread is try to marshal to the first, deadlock can ensue. So, you must be careful here, even though the DispatcherObject has made it easier to coordinate between threads.

WinForms had a somewhat similar concept to DispatcherObject in the SynchronizationContext class, though the DispatcherObject is a cleaner and easier to use design. Score one for WPF.

So, with the DispatcherObject or SynchronizationContext classes, it's possible to create background operations that communicate with our UI by marshalling operations onto the "UI thread" (the thread on which the UI components are created). However, there's still a lot of dirty little details you have to take into account when creating such a background process. So, WinForms provided us with a BackgroundWorker class. This class would greatly simplify the code required to create a background task, allow it to be cancelled and report progress on the UI thread. WPF doesn't have a similar concept, so score one for WinForms.

Other people have pointed out that you can use the BackgroundWorker in a WPF application, and there's plenty of examples of how to do this. It's not rocket science, really, so I'm not going to cover that. What I am going to do, and the whole purpose of the post, is tell you that BackgroundWorker is a sub-optimal solution in WPF, and provide you with the basis of a better solution.

Why is BackgroundWorker sub-optimal? Because the design requires you to use an event handler in order to update your UI on the progress of the operation. This is WPF. We don't want to have to write an event handler that will update our UI. We want to use data binding and no code at all!

This is fairly easy to achieve. I'm not going to provide code for this here, because I'm still working on the concept. But it should be easy enough for you to take the idea I'm about to describe and run with it.

What I'm working on is what I'm calling a BackgroundTask. This is a class that works very similarly to the way the BackgroundWorker does. However, there is no ProgressChanged event on the BackgroundTask. Instead, there's a PercentProgress property which the UI can data bind to. BackgroundTask is a DispatcherObject, so it has thread affinity, and by convention should be created on the "UI thread". The background process will then use the magic of DispatcherObject to marshal changes to the PercentProgress property onto the UI thread, where INotifyPropertyChanged can notify the data binding that it needs to be updated.

This is a very simple concept, but the result is a much easier to use component in WPF. More importantly, this is just the tip of the iceberg for what's possible with the idea. Imagine we give these BackgroundTask objects a Title property that can also be used in data binding to display on the UI. Then imagine a BackgroundTaskCollection that holds running BackgroundTask instances (which would be automatically removed from the collection when the task completes). Now our UI can display information about multiple running background tasks through simple WPF data binding magic. Now imagine we have other properties on the BackgroundTask that can also be used in data binding to display even richer information about our background process. Doesn't this concept start to sound very exciting?

Now, here's another huge bonus to this design. Let's imagine we have some domain model (data model, what ever name you wish to use) objects which our UI displays through data binding. Imagine that these models are not thread safe (they probably shouldn't be). Then imagine we need to add some long running process that's going to modify these domain objects. We don't want to run this process on the UI thread, because it would cause our UI to become unresponsive for an extended period of time. We don't want to, or can't, modify the domain object, however, in order to make it thread safe. So, what do we do? Well, you don't have to do much if you're using a BackgroundTask concept like I just described. The operation you're running in the background can use the BackgroundTask to marshal operations that modify the domain object onto the "UI thread". Your UI will update itself through the magic of data binding. Problem solved with a minimal amount of code, and no impact to your current domain object design.

The first rule of WPF

Wed, 20 Aug 2008 16:28:38 GMT

Avoid control inheritance.

I knew this rule. I've read it several times from many different sources. I've even given this advice to others. However, I'm also guilty of forgetting this rule.

Recently, I had the need for a MaskedTextBox in WPF. Marlon Grech, a fellow WPF Disciple, has a great article about how he created such a control for his AvalonControlsLibrary. Having read that post, my first inclination was to create my own MaskedTextBox (not a matter of NIH syndrome, but the lesser evil of simply not wanting to deal with the legal paperwork necessary to use Marlon's code at work). I spent a few days perfecting this control (there's a lot of corner cases you have to deal with, and I wanted full MaskedTextBox functionality, which makes it even more difficult). Once I was done, a coworker pointed out to me that we didn't pick up the Aero styling that our application uses. It's a simple fix at an application level, but not so easy to fix at a library level. Not a huge deal, but this got me to thinking about how to address the problem. Then it dawned on me... I shouldn't have created a MaskedTextBox at all!

You see, if I'd followed the "first rule of WPF", I wouldn't have had the styling issue.

So, what's the better solution here, then? Well, you simply use attached properties and behaviors instead! Here's a naive example of this concept. Please beware that this is NOT a complete solution, and won't begin to work for you as is. It only is here for illustrative purposes. I can't publish a complete solution since I developed this during work hours. However, with this illustration, it shouldn't be too difficult to develop a complete solution. Anyway, on to the code.

public class MaskedText : IDisposable
{
    private readonly TextBox _target;
    private MaskedTextProvider _provider;

    private MaskedText(TextBox target)
    {
        _target = target;
        _target.PreviewTextInput += OnPreviewTextInput;
        CreateProvider();
    }

    public void Dispose()
    {
        _target.PreviewTextInput -= OnPreviewTextInput;
    }

    private void OnPreviewTextInput(object sender, System.Windows.Input.TextCompositionEventArgs e)
    {
        e.Handled = true;
        ReplaceText(e.Text);
    }

    private void CreateProvider()
    {
        string text = _target.Text;
        if (_provider != null)
        {
            text = _provider.ToString(false, false);
        }

        _provider = new MaskedTextProvider(
            GetMask(_target),
            CultureInfo.CurrentCulture,
            true, // allow prompt as input
            GetPromptChar(_target),
            '\0',
            false); // Ascii only

        int testPosition;
        MaskedTextResultHint hint;
        _provider.Replace(text, 0, _provider.Length, out testPosition, out hint);
        SetText();
    }

    private void SetText()
    {
        int start = _target.SelectionStart;
        _target.Text = GetFormattedDisplayString();
        _target.SelectionStart = start;
        _target.SelectionLength = 0;
    }

    private string GetFormattedDisplayString()
    {
        bool flag;
        if (_target.IsReadOnly)
        {
            flag = false;
        }
        else if (DesignerProperties.GetIsInDesignMode(_target))
        {
            flag = true;
        }
        else
        {
            flag = !GetHidePromptOnLeave(_target) || _target.IsFocused;
        }

        return _provider.ToString(false, flag, true, 0, _provider.Length);
    }

    private void ReplaceText(string text)
    {
        int start = _target.SelectionStart;
        int end = start + _target.SelectionLength - 1;

        int testPosition;
        MaskedTextResultHint hint;
        if (end >= start)
        {
            _provider.Replace(text, start, end, out testPosition, out hint);
        }
        else
        {
            _provider.InsertAt(text, start, out testPosition, out hint);
        }

        if (hint == MaskedTextResultHint.Success ||
            hint == MaskedTextResultHint.CharacterEscaped ||
            hint == MaskedTextResultHint.NoEffect ||
            hint == MaskedTextResultHint.SideEffect)
        {
            SetText();
            _target.SelectionStart = testPosition + text.Length;
            _target.SelectionLength = 0;
        }
        else
        {
            //RaiseMaskInputRejectedEvent(hint, start);
        }
    }

    #region Instance

    private static readonly DependencyProperty InstanceProperty =
        DependencyProperty.RegisterAttached("Instance", typeof(MaskedText), typeof(MaskedText),
            new FrameworkPropertyMetadata((MaskedText)null));

    private static MaskedText GetInstance(DependencyObject d)
    {
        return (MaskedText)d.GetValue(InstanceProperty);
    }

    private static void SetInstance(DependencyObject d, MaskedText value)
    {
        d.SetValue(InstanceProperty, value);
    }

    #endregion

    #region Mask

    public static readonly DependencyProperty MaskProperty =
        DependencyProperty.RegisterAttached(
            "Mask",
            typeof(string),
            typeof(MaskedText),
            new FrameworkPropertyMetadata((string)null, new PropertyChangedCallback(OnMaskChanged), new CoerceValueCallback(CoerceMaskValue)),
            new ValidateValueCallback(IsMaskValid));

    public static string GetMask(DependencyObject d)
    {
        return (string)d.GetValue(MaskProperty);
    }

    public static void SetMask(DependencyObject d, string value)
    {
        d.SetValue(MaskProperty, value);
    }

    private static void OnMaskChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        if (e.NewValue == null)
        {
            Unattach(d);
        }
        else
        {
            Attach(d);
        }
    }

    private static object CoerceMaskValue(DependencyObject d, object value)
    {
        string mask = (string)value;
        if (string.IsNullOrEmpty(mask))
        {
            return null;
        }
        return value;
    }

    private static bool IsMaskValid(object value)
    {
        string mask = (string)value;
        if (string.IsNullOrEmpty(mask))
        {
            return true;
        }

        foreach (char ch in mask)
        {
            if (!MaskedTextProvider.IsValidMaskChar(ch))
            {
                return false;
            }
        }

        return true;
    }

    #endregion

    #region PromptChar

    public static readonly DependencyProperty PromptCharProperty =
        DependencyProperty.RegisterAttached(
            "PromptChar",
            typeof(char),
            typeof(MaskedText),
            new FrameworkPropertyMetadata('_', FrameworkPropertyMetadataOptions.None, new PropertyChangedCallback(OnPromptCharChanged)),
            new ValidateValueCallback(IsPromptCharValid));

    public static char GetPromptChar(DependencyObject d)
    {
        return (char)d.GetValue(PromptCharProperty);
    }

    public static void SetPromptChar(DependencyObject d, char value)
    {
        d.SetValue(PromptCharProperty, value);
    }

    private static void OnPromptCharChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        MaskedText maskedText = GetInstance(d);
        if (maskedText != null)
        {
            maskedText._provider.PromptChar = (char)e.NewValue;
            maskedText.SetText();
        }
    }

    private static bool IsPromptCharValid(object value)
    {
        char ch = (char)value;
        return MaskedTextProvider.IsValidPasswordChar(ch);
    }

    #endregion

    #region IncludePrompt

    public static readonly DependencyProperty IncludePromptProperty =
        DependencyProperty.RegisterAttached(
            "IncludePrompt",
            typeof(bool),
            typeof(MaskedText),
            new FrameworkPropertyMetadata(false, new PropertyChangedCallback(OnIncludePromptChanged)));

    public static bool GetIncludePrompt(DependencyObject d)
    {
        return (bool)d.GetValue(IncludePromptProperty);
    }

    public static void SetIncludePrompt(DependencyObject d, bool value)
    {
        d.SetValue(IncludePromptProperty, value);
    }

    private static void OnIncludePromptChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        MaskedText maskedText = GetInstance(d);
        if (maskedText != null)
        {
            maskedText.CreateProvider();
        }
    }

    #endregion

    #region HidePromptOnLeave

    public static readonly DependencyProperty HidePromptOnLeaveProperty =
        DependencyProperty.RegisterAttached(
            "HidePromptOnLeave",
            typeof(bool),
            typeof(MaskedText),
            new FrameworkPropertyMetadata(false, new PropertyChangedCallback(OnHidePromptOnLeaveChanged)));

    public static bool GetHidePromptOnLeave(DependencyObject d)
    {
        return (bool)d.GetValue(HidePromptOnLeaveProperty);
    }

    public static void SetHidePromptOnLeave(DependencyObject d, bool value)
    {
        d.SetValue(HidePromptOnLeaveProperty, value);
    }

    private static void OnHidePromptOnLeaveChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        MaskedText maskedText = GetInstance(d);
        if (maskedText != null)
        {
            maskedText.SetText();
        }
    }

    #endregion

    private static void Attach(DependencyObject d)
    {
        TextBox textBox = d as TextBox;
        if (textBox != null)
        {
            MaskedText maskedText = GetInstance(d);
            if (maskedText == null)
            {
                maskedText = new MaskedText(textBox);
                SetInstance(d, maskedText);
            }
            else
            {
                maskedText.CreateProvider();
            }
        }
    }

    private static void Unattach(DependencyObject d)
    {
        MaskedText maskedText = GetInstance(d);
        if (maskedText != null)
        {
            maskedText.Dispose();
            SetInstance(d, null);
        }
    }
}

Usage is quite simple.

        <TextBox Margin="2" local:MaskedText.Mask="00/00/0000" local:MaskedText.PromptChar="?"/>

We're no longer using a MaskedTextBox, but instead we use attached properties and behaviors to make existing TextBox controls behave appropriately.

With Styles, Templates, Decorators (check out the SpinDecorator by MindScape, for example) and attached properties and behaviors you can accomplish most of the things that you used to have to roll a new control for. In the end, what you get is usually a more reusable piece of functionality than what you could get through inheritance. For instance, the MaskedText class could be modified to support more than just a TextBox, giving you the same behavior for, say, a ComboBox, while inheritance limits how you can reuse the functionality.

WPF sure is powerful.

VisualStudio 2008 and .NET Framework SP1

Tue, 12 Aug 2008 14:06:14 GMT

These are now available, and there's much new in here. I'm going to provide some links to the pertinent stuff.

VS 2008 Service Pack 1:

Executable: http://go.microsoft.com/fwlink/?LinkId=122094 (Direct Link)
Iso: http://go.microsoft.com/fwlink/?LinkId=122095 (Direct Link)

VS 2008 Express Editions with Service Pack 1:

Executable: http://go.microsoft.com/fwlink/?LinkId=123679
ISO: http://go.microsoft.com/fwlink/?LinkId=123680

VS Team System 2008 Team Foundation SP 1:

http://go.microsoft.com/fwlink/?LinkId=124829

.NET Framework 3.5 Service Pack 1

http://go.microsoft.com/fwlink/?LinkId=124150

Team Foundation Server

Team Foundation Server 2008 SP1 (TFS Installation Guide)

A general description of the release can be found here.

Here's a list of some of the new WPF features, with links to information about them.

Item Container recycling: http://msdn.microsoft.com/en-us/vstudio/products/cc533447.aspx
TreeView virtualization: http://phizzpop.visitmix.com/blogs/techniques/archive/2008/07/06/improving-your-wpf-3-5-sp1-controls-performance.aspx
Writable bitmap: http://channel9.msdn.com/posts/AdamKinney/WPF-35-SP1-Graphics-with-David-Teitlebaum/?Page=3
StringFormat: http://blogs.msdn.com/llobo/archive/2008/05/19/wpf-3-5-sp1-feature-stringformat.aspx
RenderMode and SoftwareOnly: http://blogs.msdn.com/jgoldb/archive/2007/10/10/performance-improvements-in-wpf-in-net-3-5-3-0-sp1.aspx
Deferred scrolling: http://dotnet.org.za/rudi/archive/2008/05/22/scrolling-performance-in-wpf.aspx
Alternating row style support: http://blogs.msdn.com/vinsibal/archive/2008/05/28/wpf-3-5-sp1-feature-alternating-rows.aspx
Null value conversion and handling
Item-level validation: http://blogs.msdn.com/vinsibal/archive/2008/08/11/wpf-3-5-sp1-feature-bindinggroups-with-item-level-validation.aspx
MultiSelector support
IEditableCollectionView support: http://blogs.msdn.com/vinsibal/archive/2008/05/20/wpf-3-5-sp1-feature-ieditablecollectionview.aspx
Extensible Shader Effects: http://runtothehills.org/rob/archives/180
D3DImage: http://www.codeproject.com/KB/WPF/D3DImage.aspx
SplashScreen: http://tozon.info/blogs/andrej/archive/2008/08/11/Splash-Screen-in-WPF.aspx

There were some things left out of SP1 that we had been under the impression were "in the works". Amongst these were a DateTimePicker and a DataGrid. These did not make it into SP1, but it looks like we'll be getting them "out of band" prior to their inclusion in some future WPF update. The DataGrid has already been released to CodePlex in what's being called the "WPF Toolkit", with the promise of this being the mechanism for introducing several other WPF features "out of band".

If I've missed any features, or if links are available for any of the features I didn't provide links for, let me know and I'll update this post.

Randomize Extension

Fri, 01 Aug 2008 17:57:13 GMT

I'm not sure how useful this is, but it's a fun little thought experiment at the very least. The goal here is to randomize the order of an IEnumerable<T> via an extension method. It's actually a rather simple one liner (well, two if you count the creation of the Random instance). This specific implementation isn't optimal, and it suffers all the same issues as the pseudo random number generator Random, since it's built on that. It does illustrate the power of functional programming and LINQ, though.

public static class RandomExtension
{
    public static IEnumerable<T> Randomize<T>(this IEnumerable<T> self)
    {
        return self.OrderBy(i => random.Next());
    }

    private static Random random = new Random();
}

Now you can easily iterate randomly over any enumerable. LINQ/functional programming is quite fun, IMHO.

Edit 8/28: Greatly simplified the implementation of this extension method. The previous implementation was clever, but just not as efficient. Looking at how simple this implementation is, you could argue there's little reason to wrap it up in an extension method.

Attached Read-only Collection Dependency Properties

Mon, 28 Jul 2008 20:54:47 GMT

Oh wow! This is one I've been wanting almost since the day I started learning WPF. It seemed like such a huge thing missing from WPF. How in the heck do you manage to make an attached read-only dependency property with a collection type?

At first blush, many of you are thinking "What's the big deal? Attached read-only dependency properties are clearly documented and easy to implement." Very true. But if you're thinking that, you're glossing over the critical bit here: the type of this property is supposed to be a collection. "So what?" is your response? Well, smarty, how do you initialize that property? See, if we rely on the dependency property's "default value" mechanism, since this is an attached property every instance will have that value. Now, what you need to be able to do here is lazily create the collection on first access. However, WPF doesn't provide you with any callbacks for retrieving the value, only for setting the value, and the XAML parser bypasses the CLR "get wrapper". So, there's no place to lazily instantiate the collection. I searched high and low for a solution here. I even talked directly with several Microsoft WPF developers. I think I may have even made an official request for an event to hook into for this purpose. In the end, though, I was left wanting.

That is, until today. John Gossman e-mailed me today with a solution to this problem that works with the current WPF system. Holy smokes!

The key to his solution lies with the fact that I didn't fully understand WPF (because this something that's implied and not spelled out in the documentation). Remember when I said the XAML parser bypasses the CLR "get wrapper"? Well, that's not always true. It seems that if you register the dependency property with a "name" that differs from the CLR name, the XAML parser will call your CLR "get wrapper" instead of bypassing it and going directly to GetValue. This may not make a lot of sense with out an example. Here's such an example (I'm not including the code for the Foo type, as it's not really relevant):

public class FooCollection : ObservableCollection<Foo>
{
    public static readonly DependencyPropertyKey InstancePropertyKey =
        DependencyProperty.RegisterAttachedReadOnly("InstanceInternal",
        typeof(FooCollection),
        typeof(FooCollection),
        new UIPropertyMetadata(null));

    public static readonly DependencyProperty InstanceProperty = InstancePropertyKey.DependencyProperty;

    private static void SetInstance(DependencyObject obj, FooCollection value)
    {
        obj.SetValue(FooCollection.InstancePropertyKey, value);
    }

    public static FooCollection GetInstance(DependencyObject obj)
    {
        if (obj == null) throw new ArgumentNullException("obj");
        FooCollection foos = obj.GetValue(FooCollection.InstanceProperty) as FooCollection;
        if (foos == null)
        {
            foos = new FooCollection();
            SetInstance(obj, foos);
        }
        return foos;
    }
}

The key above is the first parameter passed to RegisterAttachedReadOnly: "InstanceInternal". Since the name is different than the implied CLR name ("Instance"), the XAML parser will now call our GetInstance method, which does the lazy creation. With this in place, the following XAML code actually works (it doesn't do anything useful, mind you, as this isn't a meaningful example beyond illustrating the concept of lazily creating the read-only attached collection dependency property).

<Window x:Class="WpfAttachedCollection.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:ui="clr-namespace:WpfAttachedCollection"
    Title="Window1" Height="300" Width="300">
    <ui:FooCollection.Instance>
        <ui:Foo Name="Bar"/>
    </ui:FooCollection.Instance>
    <Grid>
        
    </Grid>
</Window>

This is one case where the VisualStudio designer fails me. I get an error "The attachable property 'Instance' was not found in type 'FooCollection'." I'm not sure what the cause of the failure here is, but when I running the executable, it actually does work. A little more work and I can add a button that displays the added Foo objects in a MessageBox.Show, just to prove to myself that everything is working.

Like I said, this isn't exactly documented in the MSDN. It's only implied. The relevant documentation given to me by Mr. Gossman is this:

Implications for Custom Dependency Properties
Because the current WPF implementation of the XAML processor behavior for property setting bypasses the wrappers entirely, you should not put any additional logic into the set definitions of the wrapper for your custom dependency property. If you put such logic in the set definition, then the logic will not be executed when the property is set in XAML rather than in code.
Similarly, other aspects of the XAML processor that obtain property values from XAML processing also use GetValue rather than using the wrapper. Therefore, you should also avoid any additional implementation in the get definition beyond the GetValue call.
The following example is a recommended dependency property definition with wrappers, where the property identifier is stored as a public static readonly field, and the get and set definitions contain no code beyond the necessary property system methods that define the dependency property backing.

Mr. Gossman assures me the behavior here won't change, because it's relied upon by too much existing code. So, maybe it will be documented in the future, but for now you can feel safe in make use of this "hack". I owe Mr. Gossman a huge thank you for providing this to me, and I'm very happy to provide a post here for future Googlers.

Update: Looks like Mr. Gossman blogged about this as well.

Rant: $%!#(* Grid

Mon, 21 Jul 2008 14:07:18 GMT

I'm a tad frustrated by the default templates used by VisualStudio and Expression Blend for WPF. The XAML always starts you out with a Grid. WTF?

The Grid panel is the most inefficient of the panels. It's also not all that easy to use for most layouts. In other words, its the layout I would expect most developers to use the second least often (Canvas takes the bottom spot).

Don't get me wrong. There's plenty of scenarios in which Grid is your best layout choice. However, there's even more scenarios where it's not. Rarely is it the panel I'll want my Window/Page to use by default. I almost always rip that Grid out of the generated XAML and replace it with either a DockPanel or a StackPanel.

So why the harsh tone to this rant? After all, it's not that big of a deal to replace it, if it's not appropriate.

The tone is harsh, because having Grid as the default panel generated by tools is leading the unwashed developers into some bad habits. Most developers don't understand why Grid isn't as appropriate as other panels. When they see it being used by default, they think it's the panel they should fall back on by default. This leads to an overuse of the panel. That really bothers me. How many times have you seen a Grid used when there's a single column and/or row, for instance?

Sorry, this is partially a religious debate. The performance of a Grid isn't so bad as to matter most of the time. But I still have the hairs on the back of my neck stand on end the majority of the time I see a Grid used in WPF. The fact that the generated XAML encourages this doesn't help.

Update: Here's a classic example. The recently released Prism contains a "view" called OrdersToolbar. The OrdersToolbar.xaml file contains some lovely code in which the default template's Grid element was left in the source. It's only child element is a horizontal StackPanel that really defines the layout for the user control. Remove the Grid and the resulting user control is functionally identical, with easier to understand XAML markup and theoretically better performance (yeah, the perf hit here is not noticeable to the user and probably very difficult to measure, so I don't want to make too much out of that, but it is still there). Maybe the template shouldn't include anything but the Window/Page/UserControl, but it certainly shouldn't include a Grid, IMHO.

An object you can depend on

Wed, 21 May 2008 17:21:22 GMT

Sorry for that. I needed a catchy title ;).

Well, now that I'm a WPF Disciple I should probably blog more about WPF. What's interesting though, is despite the fact that I'm now working on a WPF project, most of the coding I've been doing lately has not been UI related. So, not much to blog about WPF.

Well, over lunch today my mind was wandering over the stuff I have worked on lately. Among them was the IoC container I've been tooling about with. One of the things I did with the container was to extend the functionality through extension methods. Worked great, but occasionally your extensions needed new state information that didn't exist on the object. Well now, this ties back to WPF after all.

See, there's this concept in WPF that directly addresses this. It's called an "attached property". An attached property is a property associated with an object instance, but the backing store isn't the object itself. This is accomplished through DependencyObject and DependencyProperty classes. A DependencyObject has GetValue() and SetValue() methods that take a DependencyProperty as a parameter, and get/set values for that dependency property through some magical backing store that's not actually part of the object (basically the storage is some giant HashMap). An attached property is a special type of DependencyProperty that allows you to attach values to any DependencyObject, not just the object on which the DependencyProperty is defined.

So, by turning my ObjectContainer into a DependencyObject, I can allow extension methods to maintain their own state information on the container they are extending! Such a simple concept, and yet it didn't dawn on me to do this in my initial implementations. I rolled all of the necessary plumbing to track associated external state information by hand, and did it every time I needed new state information in a new extension method. What a waste of time and effort! :)

I think I'm starting to fall in love all over again with DependencyObjects. I've avoided using them anywhere but at the UI layer. I thought it was wrong to bring in all of this baggage at the data/domain layer. After all, INotifyPropertyChanged gave me everything I need at that level, and Don Box agreed with me. Well, now I think Don and I were wrong.

You see, even at the domain layer, it's not that unusual to need an "extension mechanism". Some way for a known domain object to be extended with more features under certain circumstances. We've all rolled specialized mechanisms for allowing this in the past. However, with a DependencyObject this functionality is baked in, using a mechanism that's well supported by the rest of the framework. I used to think that dependency properties were too much of a PITA to deal with unless you absolutely had to... but I think I'm changing my mind. The flexibility and functionality you gain by deriving from DependencyObject is probably enough to outweigh the development cost, especially if you use a good set of snippets.

I've done a lot of programming in dynamic languages. The ability to add functions and data to an existing object always proved invaluable in those languages. Of course, the lack of compile time checks on all of that made maintaining those code bases a bit of a PITA. It's kind of exciting to realize now that I have most of the capability to do this but in a statically checked at compile time nature.

Newest WPF Disciple

Fri, 02 May 2008 18:27:30 GMT

You have GOT to check out the newest WPF Disciple. I'm not sure I can count all of the contributions he's made to the community.

OCD - Oh is that Code Disgusting!

Fri, 02 May 2008 13:40:04 GMT

This is a little rant. If you don't like those, move along.

I think coders have been slowly becoming lazier, and now it's really started to get on my nerves. I've seen SOOO much public code lately that is just frightening! I'm not referring to the algorithms or other technical aspects of the code here, but rather to the lack of formatting.

I'm not starting a religious war here. I don't care if you put your opening brace on the same line or the next. I don't care if the braces are indented or not. I don't care if you use tabs or spaces. I don't care if indents are 3 spaces or 12. I don't care if you mark members with an "_", an "m_" or any other wart. (Well, to be fair, I do have opinions on all of those, I just don't care if your opinion differs.)

No, what I care about is consistency. It's the lack of consistency that I've been seeing lately that's lead to this rant. In fact, it goes beyond a lack of consistency. Developers aren't even TRYING to make their code readable or maintainable. Want an example of what I'm ranting about? Check out the published code in this article on CodeProject. I don't even know how hard you have to work to get code this unformatted, considering all editors today at the very least auto-indent for you. VisualStudio will even indent pasted code that originally had a different indent properly. And one of my bigger pet peeves is with extraneous blank lines. A single blank line in logical places to call out sections of code is very appropriate. I use a lot of them in my own code. But in that first code snippet there's no consistency in the way blank lines are used, and I count at least 8 lines that have no purpose existing. Worse, some of those are consecutive.

Are we really becoming to lazy to bother making our code look professional, instead of looking like it was mashed out on a keyboard by a monkey with 3 missing fingers?

Disclaimer: I don't mean to pick on the author of that CodeProject article. I've not read the article yet, and it may be of high quality, ignoring this glaring issue.

The "var" controversy

Thu, 24 Apr 2008 14:44:48 GMT

There's some blog buzz going on right now about the appropriateness of using the new C# "var" keyword. I first ran across the meme from Jean-Paul S. Boodhoo's blog, with this post. He later linked to a post by Ilya Ryzhenkov on the same subject. One of the responses on Ilya's blog read:

"The upshot here is that vars generate some serious code - all for good reason when using LINQ. But NOT for a good reason if you’re being lazy - which is the point of this whole post. If you find yourself using “var” anywhere that’s not within a LINQ statement, it’s probably not a good idea."

This response was quoting a post by Rob Conery. Let me first say, I have not read all of Rob's post (mostly because the formatting is so bad, it makes it hard to read the post, and I don't have the time to spend on the effort). Maybe this quote is taken out of context, so take what I say next with a grain of salt. This quote is utter hogwash. The "var" keyword produces no extra code. Prove it to yourself.

public class Foo
{
}

class Program
{
    static void Main(string[] args)
    {
        Foo explicitFoo = new Foo();
        var inferredFoo = new Foo();
    }
}

The resultant IL that's generated is this.

.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 1
    .locals init (
        [0] class Playground.Foo explicitFoo,
        [1] class Playground.Foo inferredFoo)
    L_0000: nop 
    L_0001: newobj instance void Playground.Foo::.ctor()
    L_0006: stloc.0 
    L_0007: newobj instance void Playground.Foo::.ctor()
    L_000c: stloc.1 
    L_000d: ret 
}

The code for the explicitly declared variable and the inferred though "var" variable is identical. Do NOT fear using "var" because of performance concerns, as there is none.

With that out of the way, where do I fall in opinion on this subject? Well, reading the various posts in this meme, there seems to be two camps. I think both are extremes. The first extreme is the "Microsoft Camp".

“Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types.”

I simply can't agree with this extreme viewpoint. Tell me how the following code can possibly be considered less readable for others?

var inferredFoo = new Foo();

The other camp, which I'll call the Boodhoo camp, though I don't have proof that Mr. Boodhoo specifically takes this extreme point of view, believe that you should always use "var". I can't agree with that extreme either. Can anyone tell me what the type of the following declaration is?

var current = Foo.Current;

We can have arguments until we're blue in the face about how better naming would have prevented this confusion. I don't buy the argument, though. First, names aren't always under your control. Second, even with better naming it's still possible to find yourself in situations where you don't have enough type information available to you in situations like this. C# is still a strongly typed language, and knowing the exact type your dealing with is important. Relying on the IDE is a no go for me, and relying on naming isn't always possible.

So, what do I think? Out of habit, I'm still not using "var" that frequently, but I see no harm in using it for your typical "new" statements like the first example. I don't know if I'll get into the habit of doing that or not, but I see no reason to try and talk anyone out of doing so. For other declarations like the second example, unless the type is anonymous, I'd probably favor the Microsoft guideline of not using "var" here. You can probably get away with it 80% of the time and I won't care, but that other 20% is enough reason for me to not recommend getting into this habit.

Edit: From a reply to Ilya's post by "Simon" we get a list of rules much closer to what I think makes sense.

Do use var for anonymous types
Do use var for initialization from constructors (var list = new List();)
Do use var for casts (var list = (IList)list;)
Consider using var where naming implies the type of the variable (var xmlSerializer = GetXmlSerializer();)

The last bullet point is the most controversial, but I can agree with it as long as developers are consciously considering the choice. For the rest, I can see no reason to recommend not using "var" in any of those situations.

IoC I can live with

Wed, 26 Mar 2008 23:31:46 GMT

I've been working on that IoC container I've blogged about. You know, the ultra-lightweight, delegate based at the root with reflection as optional, simple container. While doing so, I've also been learning about some of the other capabilities in other containers. One of the things I discovered was Guice and the "annotation" (that would be an attribute for us .NET developers) based configuration it uses. By itself, not all that exciting as I'd already expected to use attributes for specifying what to inject. But then I noticed that they allow you to annotate an interface. Wow. Now the following is working with my container.

ObjectContainer container = new ObjectContainer();
container.RegisterDynamicConstruction();
IFoo foo = container.Resolve<IFoo>();

No, nothing was left out there (other than the definition of IFoo and some other class that implements it). I've done no configuration. I just registered dynamic construction which allows the container to create types that haven't been registered by using reflection. Then I instantiated an IFoo. Resolve looked for a registered factory for IFoo, and when it didn't find one it looked at the attributes on IFoo to discover a "default" implementation type and instantiated that. This eliminates 90% of what I dislike about IoC containers. You don't have to specify a long list of configurations (in code or in some config file, doesn't really matter) to register types with the container even though 90% of the time you'll want the same type. Why should I configure a container, just because I may want to mock a service out during testing?

Granted, I'm still specifying what types to create. However, it's done in code, when defining the interface, and is applied any time I use that interface (unless overriden) in every application with out doing any further configuration. Nearly nirvana.

Unity (as well as other containers) may have this capability... I haven't looked that close. It does allow you to instantiate concrete types through reflection, which will still do injection, so it wouldn't surprise me too much if they went the extra few inches to this. If not, I believe it could be trivially added through an extension. So, the only major difference with what I'm building is the complexity/size. So there's probably not a lot of interest in what I'm building to other folks. But I want it, and it's been a fun project for discovery.

Build Your Own IoC Container

Tue, 18 Mar 2008 01:43:16 GMT

A while ago, I wrote a blog that was critical of the Unity IoC container. A lot of what I wrote I think still stands. One complaint, though, does need a (partial) retraction. I complained that Unity was reflection based instead of being delegate based. Well, this is true of Unity proper, but the Unity project includes a StaticFactoryExtension which provides an extension to do delegate based construction. This can be used like this:

container.Configure<IStaticFactoryConfiguration>().RegisterFactory<SqlConnection>(() => new SqlConnection());

This is very flexible, and does provide full functionality. It's disappointing (to me) that the base functionality is reflection based, and an extension is required to use delegates (after all, the above syntax is a bit ugly), but at least the functionality is there. Still not what I'd consider a "light weight" IoC container, and I'm still hoping to see some IoC interfaces in the BCL, but this isn't a bad container.

Anyway, because it's still not my ideal container and since I need a container for the M-V-Poo library I'm working on, I've been working on my own container. I have a long way to go, to ensure the proper balance of features while maintaining a very lightweight code base, but I thought I'd share some of what I've come up with. So, in this blog post I'm going to provide the basis for a lightweight container that you can extend into a container that fits your needs. Before we begin, I'll point out that there are a couple of other simple containers you can find in other blogs. This one is slightly different in design (and heavier), because I'm focusing on providing a lightweight container while still providing all of the plumbing necessary to extend it until it provides all of the same functionality as Unity and other larger containers.

I'll start with the container interface. As I said in my critic of Unity, I'd prefer separate interfaces for both the locator and the container. However, I'm keeping things simple here and providing only a single interface. I'm also following some of the naming conventions from Unity, though this is not a clone of the Unity APIs. When designing the interface for the container, I provided only the most verbose version of each function. The other overloads are just convenience versions, and so I'm keeping them out of the interface. That might sound odd right now, but you'll see in a moment that this is actually a fairly flexible design. That said, here's the interface.

public delegate object ObjectFactoryCallback(IObjectContainer container);

public interface IObjectContainer
{
    IObjectContainer RegisterType(Type type, string name, ILifetimePolicy liftetime, ObjectFactoryCallback callback);
    object Resolve(Type type, string name);
    IEnumerable<object> ResolveAll(Type type);
}

Oh, there's an ILifetimePolicy type in there that we've not defined yet. Let's look at it.

public interface ILifetimePolicy
{
    object GetValue(IObjectContainer conatiner, ObjectFactoryCallback callback);
}

If you've seen Unity, most of what's here should be obvious. This is a minimalist design, with all of the fluff removed. Further, you'll notice that RegisterType is delegate based instead of reflection based by the lack of a second Type parameter and the addition of an ObjectFactoryCallback delegate parameter. So, we have a very simple interface design, now let's provide an implementation.

public sealed class ObjectContainer : IObjectContainer
{
    private class Registration
    {
        public Registration(ObjectFactoryCallback callback, ILifetimePolicy lifetime)
        {
            Callback = callback;
            LifetimePolicy = lifetime;
        }

        public ObjectFactoryCallback Callback { get; set; }
        public ILifetimePolicy LifetimePolicy { get; set; }
    }

    private ObjectContainer _parent;
    private Dictionary<Type, Dictionary<string, Registration>> _registry = new Dictionary<Type, Dictionary<string, Registration>>();

    public ObjectContainer()
    {
    }

    public ObjectContainer CreateChildContainer()
    {
        ObjectContainer child = new ObjectContainer();
        child._parent = this;
        return child;
    }

    #region IObjectContainer Members

    public IObjectContainer RegisterType(Type type, string name, ILifetimePolicy liftetime, ObjectFactoryCallback callback)
    {
        Dictionary<string, Registration> registrations;
        if (!_registry.TryGetValue(type, out registrations))
        {
            registrations = new Dictionary<string, Registration>();
            _registry[type] = registrations;
        }

        Registration registration = new Registration(callback, liftetime);
        registrations[name ?? string.Empty] = registration;

        return this;
    }

    public object Resolve(Type type, string name)
    {
        object result = TryResolve(type, name);
        if (result == null && _parent != null)
            result = _parent.Resolve(type, name);
        return result;
    }

    public IEnumerable<object> ResolveAll(Type type)
    {
        Dictionary<string, Registration> registrations;
        if (_registry.TryGetValue(type, out registrations))
        {
            foreach (Registration registration in registrations.Values)
            {
                yield return Resolve(registration);
            }
        }
    }

    #endregion

    private object TryResolve(Type type, string name)
    {
        Dictionary<string, Registration> registrations;
        if (!_registry.TryGetValue(type, out registrations))
            return null;

        Registration registration;
        if (!registrations.TryGetValue(name ?? string.Empty, out registration))
            return null;

        return Resolve(registration);
    }

    private object Resolve(Registration registration)
    {
        if (registration.LifetimePolicy != null)
            return registration.LifetimePolicy.GetValue(this, registration.Callback);
        return registration.Callback(this);
    }
}

There you go, a complete IoC container that can be easily extended to have the full capabilities of Unity and other containers.

OK, I won't leave you hanging. Obviously when given just this, it seems like a very poor implementation. Even for only a delegate based container, the convenience overloads are missing, which seems like it would make this awfully cumbersome to use. And I'm sure several of you are confused about how you could possibly extend this container. There's no built in extension mechanism, like there is in Unity, and the container is sealed, for Pete's sake. Well, don't worry, I'll provide more.

First, I'll explain how to extend this. Instead of derivation or a fancy extension mechanism, I'm going to use extension methods. I created an ObjectContainerExtensions static class where I provided a host of extensions. First, let's look at how you'd define some of the convenience overloads.

public static IObjectContainer RegisterType(this IObjectContainer self, Type type, ObjectFactoryCallback callback)
{
    return self.RegisterType(type, null, null, callback);
}

public static IObjectContainer RegisterType<T>(this IObjectContainer self, ObjectFactoryCallback callback)
{
    return self.RegisterType(typeof(T), null, null, callback);
}

Pretty simple, really. From those two examples, you should be able to implement all of the the other convenience methods. One very nice benefit here is that any IObjectContainer concrete type will get the added benefit of these methods with out having to implement anything.

OK, now what about instance registration? We'll write another extension method for that, with a few convenience overloads (I'll leave the overloads as an exercise for the reader).

public static IObjectContainer RegisterInstance(this IObjectContainer self, Type type, string name, object instance)
{
    return self.RegisterType(type, name, null, c => instance);
}

This starts to show off the power of the delegate based approach. Our concrete container only knows how to register a delegate, yet we've trivially implemented an extension method that allows you to register an instance.

Great, now what about adding reflection based registration? How can I possibly do that with only a delegate based container? Why, with some extension methods, of course. I'll start with an InjectProperties method that's similar in usage to the BuildUp method in Unity. It injects properties on an existing object by using reflection and looking for properties marked with an InjectAttribute (left as an exercise for the reader).

public static object InjectProperties(this IObjectContainer self, string name, object existing)
{
    Type type = existing.GetType();
    PropertyInfo[] properties = type.GetProperties();
    foreach (PropertyInfo propertyInfo in properties)
    {
        object[] inject = propertyInfo.GetCustomAttributes(typeof(InjectAttribute), true);
        if (inject != null && inject.Length > 0)
        {
            object value = self.Resolve(propertyInfo.PropertyType, name);
            propertyInfo.SetValue(existing, value, null);
        }
    }
    return existing;
}

Again, you can provide convenience overloads for this.

Now we have the functionality we need to do property injection via reflection, but we still need a way to do constructor injection. Obviously the Resolve method should do this, but we can't extend that beyond providing special delegates when we register a type with the container. So, I'll add a couple of private static methods that we'll use as the implementation of our delegates later on. I'll also provide a private static method that can be used to create an ObjectFactoryDelegate that constructs a Type via reflection.

private static ConstructorInfo FindConstructor(Typetype)
{
    ConstructorInfo[] constructors = type.GetConstructors();
    if (constructors.Length == 0)
        throw newInvalidOperationException();

    ConstructorInfo constructorInfo = constructors[0];
    if (constructors.Length > 1)
    {
        int argCount = -1;
        bool injectFound = false;
        foreach (ConstructorInfo cur inconstructors)
        {
            object[] inject = cur.GetCustomAttributes(typeof(InjectAttribute), false);
            if (inject != nul l&& inject.Length > 0)
            {
                if (injectFound)
                    throw newInvalidOperationException();
                constructorInfo = cur;
                injectFound = true;
            }
            if (!injectFound)
            {
                ParameterInfo[] parameters = cur.GetParameters();
                if (parameters.Length > argCount)
                {
                    constructorInfo = cur;
                    argCount = parameters.Length;
                }
            }
        }
    }

    return constructorInfo;
}

private static object Create(IObjectContainer container, ConstructorInfo constructorInfo)
{
    ParameterInfo[] parameters = constructorInfo.GetParameters();
    if (parameters.Length == 0)
        return constructorInfo.Invoke(null);

    object[] parameterValues = new object[parameters.Length];
    for (int i = 0; i < parameters.Length; ++i)
    {
        parameterValues[i] = container.Resolve(parameters[i].ParameterType);
    }
    return constructorInfo.Invoke(parameterValues);
}

private static ObjectFactoryCallback TypeFactoryAdapter(Typetype)
{
    ConstructorInfo constructorInfo = FindConstructor(type);
    if (constructorInfo == null)
        throw new InvalidOperationException();

    return c =>
    {
        object result = Create(c, constructorInfo);
        return c.InjectProperties(result);
    };
}

Given this private implementation, we can now provide the RegisterType overloads for reflection based construction (again, most of the overloads are left for the reader to do).

public static IObjectContainer RegisterType(this IObjectContainer self, Type from, Type to, string name, ILifetimePolicy lifetime)
{
    return self.RegisterType(from, name, lifetime, TypeFactoryAdapter(to));
}

There you go, a lightweight container that provides a good portion of the functionality found in Unity. There's plenty of room for improvement. The code provided is not production worthy yet, and there's still functionality missing. For instance, Unity will construct a type through reflection even if the type isn't registered with the container. All you do is call Resolve with a concrete class type, and the container will construct it and do appropriate injections. With the current code, it's non-trivial to do this, because we've hard-coded the reflection into our ObjectContainerExtensions class. To keep this lightweight, I'd move that functionality out into it's own extension class, and put it into a different namespace. This allows anyone to use the functionality when implementing extensions, but keeps them out of the normal view for consumers.

Oh, there's one final thing to illustrate. You've seen the ILifetimePolicy interface, but how do you implement a policy? Here's the requisite SingletonLifetimePolicy.

public class SingletonLifetimePolicy : ILifetimePolicy
{
    private object lockObject = new object();
    private object value;

    #region ILifetimePolicy Members

    public object GetValue(IObjectContainer container, ObjectFactoryCallback callback)
    {
        if (value == null)
        {
            lock (lockObject)
            {
                if (value == null)
                {
                    value = callback(container);
                }
            }
        }
        return value;
    }

    #endregion
}

I considered other designs here. Initially, I just provided delegate adapters instead of providing an ILifetimePolicy. This works great, but I think the usage would be a little foreign to a lot of C# developers who've never done any functional programming. I also considered designing the ILifetimePolicy interface so that it had an Adapt method instead of a GetValue method. This makes the API familiar to the user, but the policy developer still has to understand functional programming. I'm thinking that might be the more appropriate compromise, since it removes the concern about user's reusing a policy instance in multiple RegisterType calls, which as you can see from the implementation above would simply not work. With a functional design, it's not too difficult to provide implementations that are safe from this. I'm pretty sure I'll go with that design in my own library, but I kept the implementation here simple, in order to not detract from the lessons meant to be learned.

Prism Drop 03-12-2008

Thu, 13 Mar 2008 15:55:06 GMT

In case you haven't heard, Prism has it's first drop available. Prism is the Pattern's & Practices next take on "composite applications", which are a very specific form of M-V-Poo. Obviously, I'm interested in M-V-Poo, especially as the patterns apply to WPF. I've been tracking Prism for a while now, and I've commented on the spikes and other information leaked to us in the past, so some of you have some idea what to expect out of this post ;). Well, I might surprise you a little, actually.

This drop of Prism, though not with out serious design problems from my point of view, actually is fairly promising. One of the most important design criteria I had for a framework such as this was actually a design goal of Prism: that it be lightweight (not an all-imposing framework, limited "Prism stuff" footprint in your applications and limited number of abstractions with a small API surface area). Looking at the StockTrader reference application's source, I'd say they've done a fair job with it. In my opinion, the code for this application is a bit of a spaghetti mess. It took me a while to understand the flow and relationships/responsibilities of the various classes. I simply would have structured the code differently. However, the lightweight nature of the emerging framework (it's not yet a framework) looks like it would allow for using the concepts in an application structure more like I would prefer (specifics one what I'd prefer aren't important here).

Currently, the reference application is leaning very heavily on the UnityContainer and Dependency Injection. For those who have their own favorite DI container, don't fear, you're not locked into UnityContainer. However, I still strongly believe that DI is overused, and there are certainly applications that would prefer to not have to deal with this concept at all. So, I hope the emphasis on this pattern can be reduced. At the very least, there should be no requirements for DI within the framework, even if the reference applications rely on it. Since there's no framework yet, I can't say for sure wether or not there currently is such a dependency.

My one major complaint so far is that there's currently no solution to my one big complaint with WPF in general: event handling requires codebehind. I'm a very firm believer that the declarative approach with strong data binding is the most important aspect of WPF and other competing technologies, such as XUL. This enables very rapid UI development, and allows the UIs to be done by designers (using design tools) instead of developers (using code editors). Not that I don't believe many people will fill both roles, mind you. The one major failing with this in WPF from my point of view is that we don't have a useful equivalent to data binding for events. In XAML, event handlers (and this includes command handlers) can only specify methods that exist in the codebehind. There's a couple of problems with this. First, the codebehind is very tightly coupled to the XAML (they are part of the same partial class!), which makes it awkward to maintain the separation between design and development. In fact, it almost requires the designer to be enough of a developer to be able to create the handlers and implement them to call into the business objects. Otherwise, the developer and designer can wind up in a situation where they step on each other's toes. This isn't the end of the world, as we're still in a much better situation here than we've ever been in the past, but I want full separation! Then there's the other problem with this, namely that a good portion of the time you want events to be handled by other objects and it's awkward even for one person to have to create little stub handlers in the codebehind just to bridge between the two.

The reference application punts here. All the Views create stub event handlers in their codebehinds, which then raise specific events published from the View that the Presenters (or anyone else) can subscribe to. Obviously this works, and is the easiest (and a very flexible) solution. But the amount of tedious code required is depressing, even if you don't mind using codebehind, like I do. This is the ONE thing I absolutely demand from an M-V-Poo framework. (Actually, I'd much prefer a solution in WPF proper for this, but as long as we don't have a solution there, any M-V-Poo framework I'd choose to use would need to supply a solution.) There were a few concepts that were included in the spikes, that aren't used in the reference application, that seemed to be attempts to address this issue. In particular, I'm referring to the CommandDispatcher stuff. Unfortunately, I found that to be a very poor answer. First, it wasn't general enough, only allowing you to handle Commands (and RoutedUICommands at that, due to a reliance on the Name property in a way that I don't think is reliable, since I'm not aware of any requirements for this property to contain a unique value). I demand a solution that will work with any event.

Wouldn't it be ideal if WPF proper included an EventBinding markup extension with capabilities similar to the Binding markup extension, but which created event bindings instead of data bindings?

<Button Click="{EventBinding Source={StaticResource MyBusinessObject}, Handler=OnButtonClicked}"/>

With this, M-V-Poo would be trivial to implement any way you decided you wanted to implement it. Unfortunately, I don't believe it's possible to implement such a markup extension today, and thus it has to be implemented within WPF proper. But oh how I wish we had this today!!! If any WPF framework developers at Microsoft read this, please consider something like this and do anything you can to get it into this summer's service release! If you want to discuss the concept, please reply here.

Any way, overall, even though Prism isn't the M-V-Poo I'd build, I think they're off to a better start than I originally gave them credit for. It's very possible this will evolve into something that, even if it's not my M-V-Poo, it might allow me to implement my M-V-Poo.

Unity Project

Wed, 13 Feb 2008 16:14:13 GMT

Speaking about DI/IoC, Microsoft Patterns & Practices has just released an MSPL licensed DI container in the project Unity. I must say, I'm disappointed.

Here's a list of things I think Unity did wrong.

It's a P&P project, and not part of the BCL. I'm not sure we need a full DI container in the BCL, but I do believe a lot of the interfaces should be there.
They call this a "lightweight" container, but it contains two assemblies. Doesn't sound too light weight to me. I haven't fully looked into this yet, and it's possible one of the assemblies provides optional features layered on a basic container, in which case I'd have to retract what I just said in this point ;).
The interfaces are designed incorrectly. There's basically one interface, IUnityContainer, that's the driving interface. Like mentioned, I'd prefer this in the BCL, with a more generic name, such as IObjectContainer. Further, this should be split into two interfaces: the APIs to resolve instances should be separated from the APIs to configure a container, such as is done with IServiceProvider and IContainer in the BCL.
Types are resolved through reflection. At the basic level the container should be operating on "factory delegates" registered with the container. This is the most flexible design, and also provides the best performance. The reflective stuff can be built on top of this. I'd layer it, so if you don't need it you don't have to include it, but I wouldn't argue to strongly if the container (and interfaces) provided both out of the box. The fact that the factory delegate isn't present in the API at all, though, is a mistake. Just as an example, this container doesn't provide support for per-thread scope, you only have Singleton (in two varieties... one where the user creates the instance and one where the container creates the instance) and per-call. There's absolutely no way to change this, short of changing the container implementation. If we had delegate factory registration, you wouldn't have this problem.
There's still a lot of complexity here. I want a lighter weight solution.

Over all, it's not a bad library, but it doesn't deliver what I believe we need.

Using ServiceContainer

Wed, 06 Feb 2008 19:14:38 GMT

OK, in my last post I promised to show you how to use the ServiceContainer. I'm going to steal code from the Autofac home page, and rewrite it using ServiceContainer.

IServiceContainer container = new ServiceContainer();

container.AddService(typeof(IEngine),
   (c, t) => new Straight6TwinTurbo());

container.AddService(typeof(ICar),
   (c, t) => new Skyline(c.GetService(typeof(IEngine)), Color.Black));

ICar car = container.GetService(typeof(ICar));
car.DriveTo("Byron Bay");

Pretty darn similar. Autofac uses a ContainerBuilder and a declarative coding style, but other than this they are very equivalent. However, most containers allow you to specify the "scope", while the BCL ServiceContainer only provides Singleton scope, even when you supply a ServiceCreatorCallback, which is unfortunate. So, although I'll be using IServiceProvider, I won't be able to use ServiceContainer, and may consider extending both IServiceProvider and IServiceContainer to account for generics and keyed access.