My current project uses the Smart Client Software Factory which is build on top of the Composite UI Application Block from Microsofts Patterns & Practices department. SCSF is an organizational standard at my current client and we’re reusing some components of earlier projects (Large Parts of the Shell, Changetracking model etc.)

CAB is build around a very simple Dependency Injection machinery called the ObjectBuilder. I consider having the ObjectBuilder a good thing, compared to having no Dependency Injection at all. However if you’ve ever worked with any other IoC be it StructureMap, Unity, Windsor, NInject or some other container, you’ll recognize pretty fast some limitations.

Its dependency injection mechanism

• can’t really be used without attributes.
• doesn’t separate registration and creation very well, which often leads to ordering problems.
• can’t close open generic types. If you’ve ever used generic specialization you’re going to miss this.
• is pretty tightly coupled to the concept of WorkItems inside CAB.

The last point is actually the real pain point for me. The whole WorkItem API is way to general purpose and generic (meaning string based!!!) in many parts and actually not the kind of concept I would like to be a central piece of my application design. It’s not intuitive to work with it and imho doesn’t fall into the pit of success at all. Interestingly when you compare PRISM (which was also build by P&P about two years later) to CAB you’re going to recognize that the concept of WorkItems is completely missing in PRISM. Maybe I’m not the only one who feels that way.

Our team decided very early that the whole contact area of our application to the CAB framework should be limited to the presentation layer. We wanted to use a fully fledged IoC on the lower layers. This lead to an intersting challenge: How to integrate those two pipelines?

My initial thought was to replace the CreationStrategy used in CABs Builder class with something that reaches into our main container. This turned out not to be the best choice since a lot of CABs internal structure kind of relates to the standard behavior. I got something working for about half of the use cases, but it didn’t really feel good.

You know the best ideas come up when you stand under the shower. At least this happened yesterday. Actually integrating those two things is pretty straight forward. I just needed to approach the problem differently.

CAB is build around attributes. A typical CAB service might look like this.

public class NavigationService
{
    public NavigationService([ServiceDependency] IShell shell)
    {

    }
}

The ServiceDependencyAttribute tells the ObjectBuilder that it should get the dependency from the collection of Services associated with the related WorkItem used to create the class. The interesting part is that this isn’t a marker attribute. It’s a fully fledged extension point to which the ObjectBuilder delegates the essential work of resolving an instance.

Here’s the deal: You can write a custom tailored attribute which is called by the ObjectBuilder but uses you main IoC in order to resolve the dependency

The implementation of this is actually pretty easy. Here are the steps you need to implement.

1. Create a Static Gateway into your container

Attributes are by their nature kind of static and created by the framework. In order to be able to call into my container from an attribute I created a static class which holds a reference to my container (You can of course also use the P&P CommonServiceLocator for this).

public static class Container
{
    private static IContainer _container;

    public static void SetContainer(IContainer container)
    {
        _container = container;
    }

    public static void object Resolve(Type type)
    {
        return _container.Resolve(type);
    }
}

2. Create an attribute deriving from ParameterAttribute

The responsibility of ParameterAttributes in the ObjectBuilder is pretty limited. All they have to do is to create an implementation of the IParameter interface which will than be used to do the actual resolving. If you’re wondering what the membertype is, that’s the type of the parameter marked with the attribute (in the example code above this would be IShell). The CreateParameter method will automatically be called by the ObjectBuilder during the creation process.

public class ContainerDependencyAttribute : ParameterAttribute
{
   public override IParameter CreateParameter(Type memberType)
   {
       return new ContainerParameter(memberType);
   }
}

3. Create an implementation of IParameter which calls into your Static Gateway

The IParameter interface defines two methods GetParameterType and GetValue.

public interface IParameter
{
    public Type GetParameterType(IBuilderContext buildContext);
    object Getvalue(IBuilderContext buildContext);
}

We simply implement the first one with returning the member type and the the second one with a call into our Gateway.

public class ContainerParameter : IParameter
{
   private Type _typeToResolve;

   public ContainerParameter(Type typeToResolve)
   {
      _typeToResolve = typeToResolve;
   }

   public Type GetParameterType(IBuilderContext buildContext)
   {
       return _typeToResolve;
   }

   public object Getvalue(IBuilderContext buildContext)
   {
       return Container.Resolve(_typeToResolve);
   }
}

Here is an example how it is used

public class SomePresenter
{
    public SomePresenter(
         [ServiceDependency] INavigationService navigationService,
         [ContainerDependency] ISomeService someService)
    {
    }
}

At least for us, this works like a charm. What I like about the solution is that it plays nicely by the rules of the CAB framework and doesn’t fight the framework design, but still enables us to use the framework in a way we want to use it.

The interesting aspect in this approach is that you’re now able to haved mixed dependencies where one part is resolved using the surrounding CAB WorkItem and the other part is resolved using your container of choice. The whole attribute usage is limited to the presentation layer while the rest of the application can take advantage of fully fledged dependency injection without attribute, with generic specicialization and dynamic proxy generation, just to name a few options.

The core of the design is formed by a class called Subscription.

The name is quite self describing, but let me say some words about its intended purpose in my publish & subscribe implementation. The subscription is used as an endpoint for sending messages to a subscriber, hiding away the thread context (SynchronizationContext) of the related subscriber instance and the weak reference handling to the related subscriber instance from the caller. It’s a kind of mediator instance so to say. Besides that it provides some information about which message type the subscription is for.Subscriptions are created by an implementation of the ISubscriptionAssembler interface. As the name implies the main responsibility of this interface is to create subscriptions either in an explicit (create a single subscription for a given ISubscriber<TMessage> instance) or implicit (infer all subscriptions of a given instance / type) manner . . .

The current implementation (SubscriptionAssembler) uses a small wrapper around SynchronizationContext called SyncFactory to capture the thread context while building the subscription. All this factory does is that it registers a new SynchronizationContext via SyncronizationContext.Current when no context exists. This is especially useful when doing unit testing (which by default has no SynchronizationContext set).

Besides that the SubscriptionAssembler provides functionality to infer all subscriptions of a particular type and / or instance via reflection. This is done on top of the classes SubscriptionInspector and MessageInterestCache. The SubscriptionInspector realizes the relflection part, while the MessageInterestCache serves as a small cache for optimizing the performance of the assembler (message interests are only reflected once). Also included is a bit of functionality which can be used to pre-infer the message interests of a particular type, which might get handy when integrating with an InversionOfControl-container (most IoC-container split registration and type construction).

Once subscriptions have been created, they are managed by an implementation of the ISubscriptionManager interface. This means:

1. Tracking all subscriptions for a particular message type (with operations for adding / releasing and retrieving subscriptions for a particular message type).
2. Detecting and removing dead references (garbage collected instances).

The actual IMessageBus implementation called MessageBus is implemented only as a small wrapper around the ISubscriptionAssembler (for creating subscriptions) and the ISubscriptionManager (for adding and removing subscriptions explicitly). Here you can impression what it actually does:

public class MessageBus : IMessageBus
{
        private readonly ISubscriptionManager _SubscriptionManager;
        private readonly ISubscriptionAssembler _SubscriptionAssembler;

        public MessageBus(
            ISubscriptionManager subscriptionManager,
            ISubscriptionAssembler subscriptionAssembler)
        {
            Ensure.ArgumentIsNotNull(subscriptionManager, "subscriptionManager");
            Ensure.ArgumentIsNotNull(subscriptionAssembler, "subscriptionAssembler");

            _SubscriptionManager = subscriptionManager;
            _SubscriptionAssembler = subscriptionAssembler;
        }

        public void AddSubscriber(ISubscriber subscriber) where TMessage : class
        {
            Ensure.ArgumentIsNotNull(subscriber, "subscriber");

            Subscription subscription = _SubscriptionAssembler.CreateSingle(subscriber);
            _SubscriptionManager.Add(subscription);
        }

        public void ReleaseSubscriber(ISubscriber subscriber) where TMessage : class
        {
            Ensure.ArgumentIsNotNull(subscriber, "subscriber");

            _SubscriptionManager.ReleaseSubscription(subscriber);
        }

        public void SendMessage(TMessage message) where TMessage : class
        {
            Ensure.ArgumentIsNotNull(message, "message");

            var subscriptions = _SubscriptionManager.GetSubscriptions(message.GetType());

            foreach (Subscription subscription in subscriptions)
            {
                subscription.SendMessage(message);
            }
        }
}

The interface to an InversionOfControl-container is the IocBridge. This class is just a small mediator that can be used in combination with the extension method the container provides. It provides simple access points which call an ISubscriptionAssembler implementation, when an instance has been configured, try to infer all subscriptions when a new instance has been created and that release all subscriptions related to a particular instance when the instance has been removed from the container.

Regarding the design of the publish & subscribe system that’s all there is to tell . Here is a little overview over all classes.

In the last post I mentioned that my favourite IoC-container is Castle Windsor. In order to use the library there still is a little piece missing. I’ve integrated it with the WindsorContainer by implementing an IFacility.

public class PubSubFacility : AbstractFacility
{
        private IIocBridge _IocBridge;

        protected override void Init()
        {
            _IocBridge = Kernel.Resolve<IIocBridge>();
            Kernel.ComponentModelCreated += OnComponentModelCreated;
            Kernel.ComponentCreated += OnComponentCreated;
            Kernel.ComponentDestroyed += OnComponentDestroyed;
        }

        private void OnComponentDestroyed(ComponentModel model, object instance)
        {
            _IocBridge.UninstallInstance(instance);
        }

        private void OnComponentCreated(ComponentModel model, object instance)
        {
            _IocBridge.TryInstallInstance(instance);
        }

        private void OnComponentModelCreated(ComponentModel model)
        {
            _IocBridge.TryTypeInstallation(model.Implementation);
        }
}

Together with some xml the whole stuff can easily be wired together.

<castle>
<components>
<facilities>
<facility
id="PubSubFacility"
type="BjRo.CastleContrib.PubSub.PubSubFacility,
BjRo.CastleContrib.PubSub" />
</facilities>

<component id="PubSubFacade"
type="BjRo.PubSub.IocBridge, BjRo.PubSub"
service="BjRo.PubSub.IIocBridge, BjRo.PubSub"
lifestyle="Singleton" />

<component id="MessageBus"
type="BjRo.PubSub.MessageBus, BjRo.PubSub"
service="BjRo.PubSub.IMessageBus, BjRo.PubSub"
lifestyle="Singleton" />

<component id="SubscriptionAssembler"
type="BjRo.PubSub.SubscriptionAssembler, BjRo.PubSub"
service="BjRo.PubSub.ISubscriptionAssembler, BjRo.PubSub"
lifestyle="Singleton" />

<component id="SubscriptionManager"
type="BjRo.PubSub.SubscriptionManager, BjRo.PubSub"
service="BjRo.PubSub.ISubscriptionManager, BjRo.PubSub"
lifestyle="Singleton" />
</components>
</castle>

That’s it with my take on (local) publish & subscribe. It may not be perfect but it suits my needs at the moment. I’m planning to integrate the standard .NET APM in the IMessageBus interface in order allow asynchronous message sending and the common rendezvous techniques. I’m looking forward to any feedback for my solution and would like to share the code under some OS license, if someone is interested in. . .

public interface ISubscriber<TMessage>
{
     void Handle(TMessage message);
}

The generic parameter TMessage specifies the type of message the subscriber is interested in.  The message should simply be implemented by a POCO. Examples could be:

• ISubscriber<ActivePatientChanged>
• ISubscriber<ApplicationTitleChanged>
• ISubscriber<CsvExportFinished>

A consumer class wants to publish messages or to register itsself for a particular message needs to have a reference to an IMessageBus implementation. This interface serves as a consumer side facade to the pubsub system.

public interface IMessageBus
{
      void AddSubscriber(ISubscriber subscriber);
      void ReleaseSubscriber(ISubscriber subscriber);
      void SendMessage<TMessage>(TMessage message);
}

From a consumer perspective that’s all your need to known when dealing with publish & subscribe. Together with type inference it’s event nicer to use .

public class DemoMessage
{
}

public class MyListener : ISubscriber<DemoMessage>
{
     public void Subscribe(IMessageBus bus)
     {
          bus.AddSubscriber(this);
     }

     public void Handle(DemoMessage message)
     {
     }
}

public class MyPublisher
{
     private IMessageBus _Bus;

     public MyPublisher(IMessageBus bus)
     {
          _Bus = bus;
     }

     public void Demo()
     {
         _Bus.SendMessage(new DemoMessage());
     }
}

Some other characteristics also worth mentioning:

• The current implementation captures the thread context when a subscriber is registered. All callbacks will be handled on the same thread on which they were registered.
• Only a weak reference is held to the subscriber. This guarantees that a subscriber can be garbage collected although not properly unregistered from the publish & subscribe system. The implementation detects dead references and removes them automatically.

With that beeing said I would like too conclude the series about publish & subscribe with a post about the actual implementation which will follow up . . .