.NET & Funky Fresh

Asynchronous Execution, Animation and more in MVVM with Caliburn

Rob Eisenberg — Fri, 10 Jul 2009 04:21:24 GMT

On the Silverlight Insiders mailing list there’s been a discussion about the difficulties of handling animations when trying to use an MVVM architecture. I’m not going to go into the details here, as I am going to cover this more fully in a future blog post, but still, I could not resist showing off the elegant way that Caliburn solves this problem. Here is some XAML:

<TextBox x:Name="username" />
<PasswordBox x:Name="password" />

<Button Content="Login"
        pf:Message.Attach="Login(username.Text, password)" />

And here is the code from the ViewModel that Caliburn execute when the user clicks the button:

public IEnumerable<IResult> Login(string username, string password)
{
    _credential.Username = username;
    _credential.Password = password;

    var result = new Result();
    var request = new GetUserSettings(username);

    yield return new ProcessQuery(request, result, "Logging In...");

    if (result.HasErrors)
    {
        yield return new ShowMessageBox("The username or password provided is incorrect.", "Access Denied");
        yield break;
    }

    var response = result.GetResponse(request);

    if(response.Permissions == null || response.Permissions.Count < 1)
    {
        yield return new ShowMessageBox("You do not have permission to access the dashboard.", "Access Denied");
        yield break;
    }

    _context.Permissions = response.Permissions;

    yield return new OpenWith<IShell, IDashboard>();
}

Please note that the 1st, 2nd and 3rd yield statements above are all *asynchronous*, but the code within this action is executed in sequential order. The 1st yield also triggers an animation...I can also do things like this:

yield return new BeginAnimation("MyCoolAnimation");
yield return new BeginAnimation("This animation is next");
yield return new BeginAnimation("This animation plays last");

This gives the View Model a declarative way to handle animations without a need to reference the view. Also, it should be noted that the above action relies on several UI services, but I can unit test this action without needing to mock anything. The declarative nature of the action allows me to iterate over the results and simply use normal Asserts on the values. Async programming becomes synchronous and playing Animations is peachy ;)

More on this later, but I just had to show some code because I’m not sure many people know you can do this with Caliburn. On my current Silverlight project, we are making extensive use of this. It makes calling web services a breeze.

MVVM – Philosophy and Case Studies - Introduction

Rob Eisenberg — Wed, 08 Jul 2009 02:49:00 GMT

There’s been a lot of talk lately about MVVM (Model-View-ViewModel) in the WPF and Silverlight space. Recently, Ward Bell had an interesting post on the subject where he digs into some of the patterns he is using to support his MVVM triads. The WPF/Silverlight community is constantly droning MVVM, but almost no one goes beyond stating their use of the pattern or giving an overly general description of it. That’s why I enjoyed Ward’s post. He’s trying to get into the nitty-gritty of his UI architecture rather than just chanting “I'm using MVVM" and leaving it at that.

I’m pleased that the WPF/SL community is taking UI architecture seriously, but I think we have a long way to go. We need to dig deeper into the “how” of the MVVM and realize that a solid implementation is more that just creating a model and binding it to a view, with a dash of the Command pattern thrown in for good measure. In fact, saying you are using MVVM for WPF/Silverlight is sort of like saying you are using MVC for web development. It more or less states the general design approach you are taking to the UI architecture, but doesn’t say much about how the pattern is implemented or how individual features are represented within the context of that design. If you’ve been following the blogs on ASP.NET MVC, you’ve probably discovered that there is a lot more to it than just having Models, Views and Controllers. It is easy to use the MVC pattern very poorly and the same goes for MVVM.

Speaking of context…

When I first read the GoF book, I was baffled by its insistence that patterns were not tied to implementation. Sure, I understood that the Iterator pattern would be implemented differently in C++ than in C#, but I didn’t understand that other context-specific factors had a massive affect on the details of its implementation. This “phenomena” manifests itself in greater degrees with respect to how high-level the pattern is. A high-level pattern like MVC is a fine example of this. Consider how the implementations would differ between a WinForms and an ASP.NET implementation of this pattern. They would not resemble each other much at all. The WinForms version would likely look a lot like an Observer or Mediator while the ASP.NET version would be very similar to a Strategy. In fact the WinForms version would look so different, you might not even call it MVC anymore, though you started out with an MVC mindset. You could force the WinForms and ASP.NET implementations to look alike, but you would be creating a leaky abstraction by forcing an artificial context for your design to live in.

In the next couple of posts I am hoping to examine MVVM within the context of WPF/SL. What does the base form of it look like? What do more complex forms look like? Why is this pattern a good fit for WPF/SL? How does this pattern relate to MVP and MVC?

MVVM – A Simplistic View

If we take MVVM as a high level pattern, like MVC, then it becomes our general approach to architecting user interfaces. It means that we will have components in three of the following broad roles:

Models – These are the business-oriented components that are intended to be displayed or manipulated by the application. They might be traditional business objects rehydrated from the DB, messages from a web service or anything else that has business meaning independent of presentation.

Views – WPF/Silverlight is a view framework and is thus intended to provided these components. Their role is to display something on the screen. Nothing more, nothing less.

View Models – This is a special type of model, intended to be an abstraction of the UI. You can think of it as a logical representation of the UI. It is “connected” to the view at runtime through databinding.

My guess is that you probably feel pretty comfortable with the idea of a Model or a View. You can picture them in your mind. But when it comes to View Models, things get foggy. It means that we need to have a lot more discussion around what our View Models look like. But, we cannot just discuss them abstractly. We must look at specific scenarios and see how ordinary design patterns interplay to create a meaningful model of the UI. In a few words, here’s my general philosophy and what I hope will become clear as we proceed:

The same OOD techniques you use to build your backend systems are used to construct your View Models.

To that end, I am hoping to put together several posts on the subject. I am planning to contact several of my previous clients with the intention of gaining permission to discuss small portions of their applications; or to discuss them at a very high level. I want to show specific problems and demonstrate how we used common design patterns to build a rich View Model. It is my hope that this will begin a richer discussion on the topic within our community.

Caliburn v1 Release Candidate

Rob Eisenberg — Sat, 13 Jun 2009 04:19:00 GMT

On Friday I published the Release Candidate for Caliburn. You can get it here. I’m hoping to only do bug fixes and a few minor changes between now and release. There have been quite a few important changes since the Beta:

Refactored assemblies for greater ease of use.
Implemented an Application base class that supports model-first development.
Introduced IViewStrategy and the View.Model attached property.
Added CommandSource triggers
Tweaked the implementation of Actions/Commands so that it performs better and is more intelligent
Updated dependencies on other OSS projects
Added a WPF version of the LOB Sample
Factored out mini-frameworks for the both the WPF and Silverlight LOB samples.
Implemented binding validation of hierarchical path notation.
Fixed many bugs throughout the framework.
Lots of other random features and improvements…

I hope that if you are building WPF or Silverlight applications you will take some time to evaluate Caliburn and give me some feedback.

geekSpeak on MVVM with WPF and Silverlight

Rob Eisenberg — Wed, 10 Jun 2009 15:21:00 GMT

Today at 3pm EDT/12pm PDT Christopher Bennage and I will be jabbering about MVVM and UI Architecture on the MSDN Webcast geekSpeak. Please join us!

MVVM and The Origins of Caliburn

Rob Eisenberg — Mon, 18 May 2009 14:51:00 GMT

Recently Glenn Block asked some questions of the community concerning what support Microsoft should offer for the MVVM design pattern in WPF/Silverlight. I’d like to answer that question here, but in a round-about manner. I’m going to use this as an opportunity to talk about the origins of Caliburn.

About two years ago I entered an article in a contest on dotnetslackers about a prototype framework I had developed several months earlier during my free time. The sample application for the article is manufactured, but the framework was built for a real application I was working on then. At that time, I was writing a GUI test runner for NSpecify framework. I had been doing WPF development for over a year, though not for paying contracts (I built some really cool samples such as a WF designer, an interactive fiction viewer/editor, a partial implementation of the Office 2007 ribbon and a multi player online game) and was using this project to experiment with some new architectural ideas. I had long since become frustrated with the typical code-behind model and had been looking for ways to move away from it. Being heavily influenced by John Gossman’s article on MVVM, I began making greater use of Commands to enable databinding of UI to actions.

Here’s the progression I went through and suspect that many WPF developers can identify with:

Started by manually wiring events and handling them in the code-behind.
Factored logic out of the code-behind and into some sort of presentation class (Presenter, VM, etc). Event handlers became a pass-through to methods on the presentation class.
Moved away from events and towards commands. Created custom commands that hung off the presentation class and were wired to the UI through databinding.
Got tired of creating lots of commands after about 5 minutes and implemented a DelegatingCommand pattern to enable databinding on the view side, with a pass-through to a standard method on the presentation class.
Got tired of instantiating and wiring delegating commands after about 15 minutes and created a fluent interface dedicated to the task. The code looked something like this:
```
public DelegatingCommand Save
{
    get { return Execute.AsCommand(DoSave).If(CanDoSave).Async(); }
}
```
In fact, you could see the implementation of this in some early versions of Caliburn.

To answer Glenn’s first question:

Where does the platform help? Where does it hinder?

Even though the fluent interface is a pretty efficient way of binding models and views, it is still fairly limited in its capabilities. With commands you are limited to elements that implement ICommandSource only. So, if you want to have code execute on a ListBox.SelectionChanged event, you have to revert back to events and code-behind. You could try and rig something up by using InputBindings/CommandBindings which exist on all UI elements, but using gestures to simulate control-specific events is kludgey. Furthermore, InputBindings/CommandBindings have limitations due to the fact that they either are not DependencyObjects or don’t implement DependencyProperties and cannot be bound as easily, thus you have to use some sort of static class mechanism. Furthermore, commands can only have one parameter and RoutedCommands are terribly confusing and IMHO an overly complex solution to the problem. All of this is a bit shady and quite round-about in general. This leads me to a rather simple answer to Glenn’s second question:

What can we do in the platform to make life easier?

What we really want to do is bind the view directly to the methods themselves. It would be nice if we had a mechanism by which we could bind any .NET event, routed event, gesture or command with one consistent syntax.

Caliburn’s implementation of RoutedMessaging and Actions is my attempt to solve this very problem in the OSS space. Actions was the first feature I developed for Caliburn (although there are quite a few more now and many more to come) and it remains one of the most used. Here’s a snippet from one of Caliburn’s sample apps, demonstrating some of the syntax:

<Button Content="Example 1"
    Message.Attach="Divide(left.Text, right.Text) : DivideResult.Text" />
<Button Content="Example 2"
    Message.Attach="[Event Click] = [Action Divide(left.Text, right.Text) : DivideResult.Text]" />

Both these snippets do the same thing, the second is just more explicit about the details. Here’s what all this does:

Wire up to the “Click” event (Caliburn determines this to be the default in Ex1)
Send an “Action Message” whenever the “Click” event fires (again Caliburn knows that Actions are default in Ex1)
When the action executes, take the Text properties of the controls with names “left” and “right” and pass those values as parameters to the “Divide” action (a method on a class).
Perform type conversion on the parameters.
Take the return value of the action and databind it back to the Text property of the control with its name set to “DivideResult”

This demonstrates binding directly to methods from events. But you can also trigger actions based on an ICommandSource’s command execution:

Message.Attach="[CommandSource] = [Action Divide(left.Text, right.Text) : DivideResult.Text]"

Or by gesture:

Message.Attach="[Gesture MouseAction: LeftClick, Modifiers: Control] = [Action Divide(left.Text, right.Text) : DivideResult.Text]"

The “trigger” aspect of Caliburn is completely pluggable. In fact, the ICommandSource trigger implementation was a user submitted extension, much thanks to Marco Amendola. Additionally, you can plug the right part of the expression. So instead of just triggering actions, you can also trigger commands (or anything you wish to extend it too):

Message.Attach="[Event SelectionChanged] = [ContainerCommand ShowMessage(title.Text, message.Text)]"

Caliburn can resolve commands from the container (ContainerCommand) , resource dictionaries (ResoureceCommand) or through databinding (BoundCommand) and the command’s trigger doesn’t have to be an ICommandSource nor is it limited to one parameter. In fact, commands in Caliburn are built on top of actions. Which means they inherit a host of other features as well, such as ASP.NET MVC-style rescues and filters (which are extensible) and extensible ActionResults (called IExecutableResult in Caliburn). You can also decorate your action/command with an [Async] attribute and Caliburn will call it on a background thread, and automatically marshal the callback onto the UI thread (you even have control over the background task’s progress and cancellation).

As a developer, it was really important to me that I have a consistent way of wiring user interactions to my model. Furthermore, I wanted the same syntax for both WPF and Silverlight (and yes, that took a lot of work in SL2). This brings me to a key point, whatever Microsoft builds, the public API should be the same for both WPF and Silverlight.

What role do developers / designers play in your application of ViewModel?

I think that the only way to have a strong UI is through iterative development. This means constant communication between the development team and the client, but also constant communication between the developers and the designers. Keep in mind that a View and its ViewModel are a highly cohesive unit. This means that a designer is going influence what your ViewModel looks like. What I would really like is a way for Views to be more easily bound to their ViewModels. Christopher and I have often talked about how nice it would be for Caliburn to have a Cider/Expression plugin that let you wire views directly to the ViewModel (both properties and methods). And that definitely describes something I would like to see from Microsoft in this area. The next phase in designer/developer interaction in WPF and Silverlight is a ViewModel rather than code-behind centric tooling experience.

Off to Mix!

Rob Eisenberg — Mon, 16 Mar 2009 12:16:00 GMT

I'm heading out to Mix09 in Las Vegas today. If you are going to be there, please say hello. I'm looking forward to meeting people and talking about one of my new projects.

The Caliburn Beta is Live

Rob Eisenberg — Fri, 27 Feb 2009 02:15:51 GMT

Today is a long awaited day for me. Caliburn is now in official Beta. There have been many bug fixes and a ton of new features since the Alpha release last October. We’ve also been dogfooding it on several projects, one of which is NHProf. I wanted to use this post as an opportunity to summarize Caliburn’s current feature set and introduce you to the Line-Of-Business sample provided with the framework, built with Caliburn and Silverlight.

If you are in the WPF or Silverlight world, you may have spent some time trying to figure out how to cleanly architect a UI with these technologies. You may have come across the MVVM pattern through excellent articles like this one by Josh Smith or you may have found more general UI architecture guidance in Jeremy Miller’s Build Your Own Cab series or on Martin Fowler’s site. Whatever the case, its obvious that building solid UI is difficult and there are a ton of patterns and variations on patterns geared to solving common problems. The goal of Caliburn is to make building UI easier by providing a class library that eliminates the boiler-plate code often involved in implementing these solutions.

Features of the Beta

Actions

Actions extend the databinding capabilities of WPF/SL by enabling a UI to bind not only to data but to methods. Caliburn uses triggers to wire events, gestures, and attached events (extensible to any trigger type you can think of) to methods on a presentation-related class. This type of method binding removes much of the glue code involved in building an MVC or MVP architecture. Additionally, it enables very rich Presentation Model (MVVM) scenarios. In addition to basic execution of methods, Caliburn's action mechanism can pass data from the UI into the methods as parameters and bind return values back to the UI (in fact the return behavior of action is entirely extensible by implementing a custom IExecutableResult). A filter mechanism (similar to ASP.NET MVC) exists for decorating methods. Filters can affect the availability of a given action through the UI, which can be represented by automatically disabling, hiding or collapsing controls (extensible to any visualization). There are several built-in filters, but the mechanism is entirely extensible. Caliburn can also automatically execute methods asynchronously, and execute callbacks. It does all the thread marshalling for you.

Commands

Caliburn's command implementation is an alternative to WPF's and supplies very useful functionality that is altogether missing from Silverlight. As you might expect, it is an implementation of the Command Pattern. . Commands are built on top of Actions and thus share many of the same features, including multiple input parameters, filters and automatic asynchronous execution. Additionally, commands can be created in hierarchies, such that a parent command can execute multiple child commands. The parent command's availability can also be affected by its children in various ways. There are two types of composite commands available out of the box, but the mechanism is extensible. There is no limit to the depth of the command hierarchy.

MVP and Application Controller

Two common patterns that occur in applications are Supervising Controller and Application Controller. Caliburn supports architectures based on these ideas directly through its various implementations of the IPresenter interface. Often times, these types of architectures involve tricky UI lifecycle issues such as handling activation, deactivation and shutdown semantics for various UI components. The basic logic for handling these scenarios is found in Caliburn’s Presenter, PresenterManager, MultiPresenterManager and Navigator classes. By composing these classes you can create a hierarchical model representing the entire runtime state of your application. In Silverlight, you can even use the browser as an Application Controller with Caliburn’s support for deep linking.

Presentation Model and MVVM

Caliburn also supplies a set of base classes that enable transactional editing, n-level undo/redo, dirty tracking and validation. These classes are perfect for creating an editable ViewModel or representing the “Model” portion of the MVP triad when utilizing a Supervising Controller. This functionality is accomplished through a rich metadata-aware property system, similar to dependency properties, but more suited to the needs of a model rather than a view.

Testability

One of the goals of Caliburn is to make it easier to build applications right. To this effect, Caliburn has features geared around unit testing. There is currently rich support for testing databindings in WPF and a simple fluent interface for verifying change notification on model objects. Unit tests for view bindings give the developer the confidence they need to refactor their models, knowing that they will be aware of broken bindings before they run the application. Not only will they be aware that the bindings are broken, but Caliburn’s binding validator will tell you exactly where the problem is in the UI hierarchy and what the specific error was.

Many, many more features…

LOB Sample Application

In addition to the framework, you will find several samples as part of the Beta download. The most thorough demonstration of Caliburn can be found in the Silverlight Contact Manager sample. Some features you can look for are:

Dependency injection is used throughout.
Use of Actions throughout (this includes the use of Preview and Dependencies filters).
The ContactDetailsPresenter.ValidateContact demonstrates the use of a custom IExecutableResult from an Action.
- When you mouse over the 'red dot' after changing a contact, a popup will appear. That is the result of the IExecutableResult.
- IExecutableResult works in conjunction with a custom ValidationResult.
- If you have some invalid properties, you can click on notices in the popup to focus the control related to the error.

The structure of the application forms a composite hierarchy with implementers of IPresenter. This hierarchy exists at runtime. Below is an example of what might occur:
    ShellPresenter (PresenterManager)
        -> ContactListPresenter (MultiPresenterManager)
            -> N of ContactDetailsPresenter (Presenter)

*The red, blue and green outlines show the views bound to the composited presenters.

The application controller pattern is used as a top level coordinator.
Deep linking is accomplished with the DeepLinkStateManager.
The Settings class builds on top of the IsolatedStorageStateManager for simple key/value pairs stored locally.
The Model classes inherit from ModelBase and uses a special form of property declaration (similar to dependency properties). By nature of this form of definition, these classes gain the following features:
- Transactional editing support (BeginEdit, EndEdit, CancelEdit)
- Property change notification
- Dirty tracking
- Validation
- N-Level Undo/Redo support
Advanced shutdown scenarios for presenters.

In addition to Caliburn's framework, this sample demonstrates an application specific framework built on top of Caliburn, to add more convention to the way this app is built. Examples of this include:

Use of the ViewAttribute in conjunction the ViewZone to detect presenter's views, display them and wire up Action.Target.
Use of a custom set of attached properties (Bind...) to do some fancy wire up of data binding, validation, etc.
Use of the HistoryKey/HistoryInfo to aid the DeepLinkStateManager.

Finally, there are a number of other useful SL tidbits built in as well:

Visual transitions with the TransitionPresenter and implementors of ITransition.
Modal dialogs
Data bound tooltips.
UI scaling (ala ViewBox)

I hope this helps in your overall understanding of Caliburn and serves as an example of UI architecture. Feedback is welcome. Enjoy the new release and have a look at the growing developer documentation!

I Finally Sold Out to Twitter

Rob Eisenberg — Thu, 19 Feb 2009 18:37:00 GMT

http://twitter.com/EisenbergEffect

Now I'm in with the hipsters... Let's hope I can still get some work done.

A MEF Misunderstanding

Rob Eisenberg — Thu, 05 Feb 2009 19:13:00 GMT

Yesterday I wrote about integrating Caliburn and MEF along with getting things to work with IServiceLocator. I had a feeling that I was going about things all wrong and was eagerly hoping for some constructive criticism. Glenn Block was kind enough to engage with me on the subject and has agreed to publish a proper implementation of IServiceLocator for MEF. Keep an eye on his blog for that (and certainly don't use my poo poo code) .

MEF, IServiceLocator and Caliburn

Rob Eisenberg — Wed, 04 Feb 2009 22:12:48 GMT

My company just began working on a large, modular WPF project. I’ve been doing some research and recently took some time to dig into the Managed Extensibility Framework (MEF). I’m quite impressed with the direction that the project is going. MEF is going to fulfill our modularity needs quite well.

At the same time, I have refactored Caliburn to use the CommonServiceLocator that P&P released last year. Caliburn is a loosely coupled set of UI services and requires dependency injection to work. I have IServiceLocator implementations of Windsor, StructureMap, Unity and Spring.NET. Many of these implementations are based on the adapter code that can be found on the CommonServiceLocator site. Interestingly, there isn’t an implementation of IServiceLocator for MEF.

As my current project needs MEF to solve modularity concerns and Caliburn to solve UI architecture issues, I spent some time today writing an IServiceLocator adapter for MEF. It turned out not to be too difficult, but the code is not pretty. This stems from the fact that MEF’s CompositionContainer is generics based, but ServiceLocatorImplBase uses Type instances. I had to resort to using reflection to interact with the underlying container. I’m going to post the code below so that you can see how to do this sort of thing, but also in hopes that someone like Glenn can correct any stupid stuff ;) (I was hoping there is a non-reflection-based mechanism that I just didn’t see.)

In addition to implementing IServiceLocator, Caliburn needs a way to inform the container of its own components. In Caliburn you do this by either implementing IConfigurator or by providing a delegate which can take Caliburn’s ComponentInfo and register the services appropriately with the container. This is where the real MEF challenge comes in. MEF is not exactly a DI container, and thus doesn’t have the typical registration mechanism that you might expect. I wasn’t really sure what the best way to solve this problem was, so I implemented my own ComposablePart. Below is the entire MEFAdapter which implements both IServiceLocator and IConfigurator. I would appreciate feedback from any MEF experts or members of the MEF team. Much thanks in advance!

MEFAdapter

using System;
using System.Collections;
using System.Collections.Generic;
using System.ComponentModel.Composition.Hosting;
using System.Reflection;
using Caliburn.Core;
using Microsoft.Practices.ServiceLocation;

namespace Caliburn.MEF
{
    public class MEFAdapter : ServiceLocatorImplBase, IConfigurator
    {
        private readonly CompositionContainer _container;
        private readonly MethodInfo _getExportedObjectByType;
        private readonly MethodInfo _getExportedObjectByTypeAndKey;
        private readonly MethodInfo _getExportedObjectsByType;

        public MEFAdapter(CompositionContainer container)
        {
            _container = container;

            _getExportedObjectByType = _container.GetType().GetMethod("GetExportedObject", Type.EmptyTypes);
            _getExportedObjectByTypeAndKey = _container.GetType().GetMethod("GetExportedObject", new[] { typeof(string) });
            _getExportedObjectsByType = _container.GetType().GetMethod("GetExportedObjects", Type.EmptyTypes);
        }

        protected override object DoGetInstance(Type serviceType, string key)
        {
            MethodInfo genericMethod;

            if(!string.IsNullOrEmpty(key))
            {
                genericMethod = _getExportedObjectByTypeAndKey.MakeGenericMethod(serviceType);
                return genericMethod.Invoke(_container, new[] { key });
            }

            genericMethod = _getExportedObjectByType.MakeGenericMethod(serviceType);
            return genericMethod.Invoke(_container, null);
        }

        protected override IEnumerable<object> DoGetAllInstances(Type serviceType)
        {
            MethodInfo genericMethod = _getExportedObjectsByType.MakeGenericMethod(serviceType);
            var results = (IEnumerable)genericMethod.Invoke(_container, null);

            foreach(var result in results)
            {
                yield return result;
            }
        }

        public void ConfigureWith(IEnumerable<ComponentInfo> components)
        {
            var batch = new CompositionBatch();

            foreach(var componentInfo in components)
            {
                batch.AddPart(new ComponentPart(componentInfo));
            }

            _container.Compose(batch);
        }
    }
}

ComponentPart

using System;
using System.Collections.Generic;
using System.ComponentModel.Composition.Primitives;
using System.Linq;
using System.Reflection;
using Caliburn.Core;

namespace Caliburn.MEF
{
    public class ComponentPart : ComposablePart
    {
        private readonly ComponentInfo _info;
        private readonly List<ImportDefinition> _imports = new List<ImportDefinition>();
        private readonly ExportDefinition[] _exports;
        private readonly Dictionary<ImportDefinition, Export> _satisfiedImports = new Dictionary<ImportDefinition, Export>();
        private object _cachedInstance;
        private readonly ConstructorInfo _greedyConstructor;

        public ComponentPart(ComponentInfo info)
        {
            _info = info;

            _greedyConstructor = (from c in info.Implementation.GetConstructors()
                                  orderby c.GetParameters().Length descending
                                  select c).FirstOrDefault();

            if (_greedyConstructor != null)
            {
                foreach (var parameterInfo in _greedyConstructor.GetParameters())
                {
                    var parameterType = parameterInfo.ParameterType;

                    var import = new ImportDefinition(
                        def => def.ContractName == parameterType.FullName,
                        ImportCardinality.ExactlyOne,
                        false,
                        true
                        );

                    _imports.Add(import);
                }
            }

            string contractName = info.Key is string ? info.Key.ToString() : ((Type)info.Key).FullName;

            var export = new ExportDefinition(
                contractName,
                null
                );

            _exports = new[] {export};
        }

        public override object GetExportedObject(ExportDefinition definition)
        {
            if (_info.Lifetime == ComponentLifetime.PerRequest)
                return CreateInstance(definition);

            if(_cachedInstance == null)
                _cachedInstance = CreateInstance(definition);

            return _cachedInstance;
        }

        private object CreateInstance(ExportDefinition definition)
        {
            var args = new List<object>();

            if(_greedyConstructor != null)
            {
                foreach(var parameterInfo in _greedyConstructor.GetParameters())
                {
                    var arg = (from export in _satisfiedImports.Values
                               where export.Definition.ContractName == parameterInfo.ParameterType.FullName
                               select export).FirstOrDefault();

                    args.Add(arg.GetExportedObject());
                }
            }

            return args.Count > 0
                       ? Activator.CreateInstance(_info.Implementation, args.ToArray())
                       : Activator.CreateInstance(_info.Implementation);
        }

        public override void SetImport(ImportDefinition definition, IEnumerable<Export> exports)
        {
            _satisfiedImports[definition] = exports.FirstOrDefault();
        }

        public override IEnumerable<ExportDefinition> ExportDefinitions
        {
            get { return _exports; }
        }

        public override IEnumerable<ImportDefinition> ImportDefinitions
        {
            get { return _imports; }
        }
    }
}

Caliburn V1 Roadmap

Rob Eisenberg — Thu, 29 Jan 2009 22:56:40 GMT

I’ve been working hard on Caliburn in my spare time, gearing up for the V1 release. In the next two weeks, you can expect to see an official Beta 1. The beta should be pretty solid and feature rich. After the beta I’m not planning on any major feature additions, just bug fixes and usability improvements depending on the feedback I get from users. It is my desire to see version one released sometime prior to Mix09 in March.

Things that are coming in Beta 1 and are already in the trunk include:

A data binding validation api designed for use in unit tests.
A series of base classes for representing and managing various flavors of the MVP pattern as well as navigation scenarios. (This includes history/back button support in Silverlight).
A series of base classes for creating models that support transactional editing, dirty tracking, validation and undo/redo support. These models can be used to build up an editable ViewModel.

As of today there are over 400 unit tests for Caliburn and I will be adding more during the next weeks and after the beta.

There are a few things left to do before I release an official beta. They are:

Create a sample application demonstrating the MVP classes and the transactional model support.
Write documentation for the above features, based on the sample application.
Incorporate the CommonServiceLocator into Caliburn and refactor the code appropriately.

Post beta, I am thinking about the following:

Implementing a container adapter for MEF.
Implementing some container adapters for Silverlight.
Fixing bugs
Adding more unit tests.

That’s the plan! Let’s see if we can make it happen.

Tampa TDD Firestarter This Saturday!

Rob Eisenberg — Thu, 15 Jan 2009 18:52:44 GMT

From the Event Site:

Software is continually growing in complexity. What is needed for every team is a method to discover defects and bugs as soon as they are added to the system rather than after the software ships. An ongoing documentation system that is tied directly to your codebase is just as useful.

Test Driven Development aims to ease the pain of changes to your codebase as well as providing a safety net for any changes made to the system. You can easily run your test suite to find errors that were introduced to the system by a modification to the code. Tests also allow you to continually re-factor your codebase and thus create a more flexible, cohesive codebase.

In this day- long event, you will go from start to finish with a sample domain problem and how to write tests to drive functionality of the system. To accommodate existing TDD enthusiasts, we will be providing a beginner and intermediate tracks at the same time. There will be hour long presentations at the end of the day that will reinforce what you have learned during the day with surrounding practices.

Saturday, January 17, 2009

9:00 AM–5:00PM

Click here to register or call (877) 673-8368 with event ID 1032397083.

Speakers include Cory Foy, Scott C. Reynolds, Sean Chambers, Christopher Bennage and myself.

WebForms Developer Wanted

Rob Eisenberg — Tue, 06 Jan 2009 21:21:11 GMT

My company is looking for an experienced WebForms developers to take ownership of one of our small projects. The client has a need for new features and technical advice about every four to six months and this would provide an opportunity for an interested developer to make a few extra dollars on the side.

A few interesting tidbits about the project:

Originally built with .NET 1.1 but was recently updated to .NET 3.5 and VS2008, so future modifications can take advantage to the latest language and platform features.
A media focused application with potential for Silverlight additions in the near future.
Built on a custom ORM. (Has a small and simple domain model).
Has been in production for about 3.5 years.

The client is located in St. Petersburg, FL, so if you are close, that's a bonus, but it is not necessary. If you are interested, please email me a resume. Looking forward to hearing from you!

NH Prof Public Beta

Rob Eisenberg — Fri, 02 Jan 2009 16:01:00 GMT

Christoper and I have had the privelage of helping Ayende to build the UI for his NHibernate Profiler over the last couple months. Yesterday evening he released the public beta with a 30 day trial version. If you are using NHibernate, get over to the product site and download the beta. This is going to be an invaluable tool for developers using NHibernate and you can get it at a special price if you purchase during the beta period.

As a developer on this project, I had the unique opportunity to watch a master at his craft. The architecture of the product is clean and Ayende has managed to jam pack this version with a ton of NHibernate smarts. Just working on it, I gained a deeper understanding of the types of problems one can run into while using an ORM. I would not want to do another project without it.

Another exciting aspect of this application is that we are using the latest version of Caliburn in the UI architecture. Generally speaking, the UI architecture is composed of a very rich Presentation Model (MVVM) with a splash of MVP for good measure. There is almost no code-behind in the views. All communication is handled by Caliburn's action message mechanism. We were also able to use Caliburn's new testability features to cover all our views with data binding validation tests and do basic property change notification testing.

MVP Goodness!

Rob Eisenberg — Thu, 01 Jan 2009 15:54:00 GMT

Congratulations to Christopher Bennage for receiving a 2009 MVP for Client App Dev! Microsoft was also gracious enough to award me with an MVP in the same area! Let the good times roll...