var Matt = new Hero();

The Magic of IoC

Matthew Abbott — Wed, 25 Aug 2010 19:29:37 +0000

I was bored…

…so I decided to design an IoC Container! This actually turned out to be a lot of fun too. I’d like to firstly state that a) there is no reason for this code, and b) this is not a replacement for established IoC solutions, such as Unity, Castle Windsor, Ninject, Authofac, StructureMap, and lastly c) this is not production code. Ah, that’s better.

The need for Inversion of Control (IoC)

Inversion of Control (IoC) is not a new concept, it’s been around for quite a while, and many will be familiar with some of the IoC containers listed above. IoC is the concept changing the behaviour of a software system to allow decoupling of components within the framework. The way I always understood IoC is that in a traditional software design, you may have a central piece of code which essentially orders other bits of code to do things specifically. I.e. “you do that, with this, and you do that, with this other bit”; in a software design that implements IoC, the central piece of code no longer orders the other bits round, rather the component requests an instance of a type so it can perform exactly what is is required to do, i.e. “can I have that, as I need to do this”.

This design pattern allows us to greatly modularise and decouple the components within our system. If we wanted to, we can rip one part out, and throw in another part. The dependant components are none the wiser. Now if you google (or bing!), you will find plenty of articles describing IoC in much fuller detail, so I won’t bore you here other than to say, IoC can benefit a software design greatly, allowing you to somewhat future-proof your code, plus increase testability and greatly segregate logical portions of code without having to worry about all that “wire-up”.

IoC Containers

IoC Containers are fabulous bits of code. They hide away the complexities of type management and they also handle dependancy injection (DI) for you. DI is the final piece of glue, it allows our containers to create our requested types without us (the developers) having to worry about explicity creating arguments for type construction (Constructor Injection), or member values (Property Injection). If you have your types registered with your favourite IoC container, then the container should automatically be able to create the appropriate types and inject them into the type being created. Let’s have a look at a quick example:

public class ConsoleLogger : ILogger
{
  public ConsoleLogger(IObjectFormatter formatter)
  {
    // Stuff here...
  }
}

In the simple code above, we have a class, the ConsoleLogger. It’s only task is write objects to the console window. Now, I’ve introduce a dependancy, an instance of IObjectFormatter that will be used to format the objects before the ConsoleLogger writes them to the output. Because this is a required dependancy, I’ve made it part of the constructor. If all goes well and I have registered an instance of IObjectFormatter with my container, when my container resolves my request for an ILogger, it should be able to create an instance of it, and inject the available IObjectFormatter into the constructor. I haven’t had to worry about any of that! Genius.

A simple IoC Container

Ok, so onto the good stuff. There wasn’t any real reason for me to design my IoC container, I just wanted to see if I could do it! It was one of those “challenge-yourself” moments, and I think I won! Now, its not a perfect design, so I’m hoping I get quite a lot of constructive criticism too.

There are 3 major parts to this IoC design; IContainer, IBuildStrategy and ILifetimeStrategy. The container is pretty obvious, but what are the other parts I hear you not ask?

IBuildStrategy
A build strategy is responsible purely for creation of types. This is where objects are built, and wars are won. Here is the interface:

/// 
/// Defines the required contract for implementing a build strategy.
/// 
public interface IBuildStrategy
{
    #region Methods
    /// 
    /// Creates an instance of the specified type.
    /// 
    /// The type to create.
    /// The current container.
    /// An instance of the specified type.
    object CreateInstance(Type type, IContainer container);
    #endregion
}

It’s a simple interface, needing only the type to create, and the current container. This design supports a single build strategy per type, and bundles three pre-built strategies:

DefaultBuildStrategy – This will create an instance of a type using the default public constructor.
ConstructorBuildStrategy – This will create an instance of a type using a constructor with parameters, or a parameterless constructor that is not public. This will resolve dependancies using the current container and inject them into the required constructor.
InstanceBuildStrategy – This always returns the exact same instance each time, and is used when you register a type with a pre-built instance.

Ok, they probably could have been named better…

ILifetimeStrategy
A lifetime strategy is responsible for managing the lifetime of an instance created by the container. By default, this design ships with two strategies:

SingletonLifetimeStrategy – Manages a single isntance of a type for the lifetime of the container. Any calls always result in the same instance being returned.
AlwaysCreateLifetimeStrategy – Always creates a new instance using a build strategy for every call to resolve.

The interface is a little more developed:

/// 
/// Defines the required contract for implementing a lifetime strategy.
/// 
public interface ILifetimeStrategy : IDisposable
{
    #region Methods
    /// 
    /// Resolves an instance of the specified type.
    /// 
    /// The type to resolve.
    /// The current container.
    /// The build strategy used to create an instance of the type.
    /// A resolves instance of the specified type.
    object Resolve(Type type, IContainer container, IBuildStrategy build);

    /// 
    /// Registers an object modifier with the lifetime strategy.
    /// 
    /// The modifier to register.
    void RegisterModifier(IObjectModifier modifier);
    #endregion
}

Ignoring the RegisterModifier stuff, we can see that a lifetime strategy must resolve an instance. I didn’t call this method “Create”, because it may not be creating an instance. We pass in a build strategy for it to use if it needs to create an instance.

By combining these interfaces, we now have a mechanism for instance lifetime management and instance creation, two essential building blocks for an IoC container.

Building the container

Well, we have our under pinnings, but how does the container make use of it all? Well, lets have a look at the interface:

/// 
/// Defines the required contract for implementing a container.
/// 
public interface IContainer
{
    #region Events
    /// 
    /// Fired when a component is registered with the container.
    /// 
    event EventHandler ComponentRegistered;
    #endregion

    #region Properties
    /// 
    /// Gets the default lifetime strategy to use.
    /// 
    LifetimeStrategy DefaultLifetimeStrategy { get; set; }
    #endregion

    #region Methods
    /// 
    /// Gets the build strategy for the specified type.
    /// 
    /// Gets the build strategy for the specified type.
    /// A  for the specified type.
    IBuildStrategy GetBuildStrategy(Type type);

    /// 
    /// Gets an instance of the specified type.
    /// 
    /// The type of instance to get.
    /// An instance of the specified type, or the default if no instance can be created.
    T GetInstance();

    /// 
    /// Gets an instance of the specified type.
    /// 
    /// The type of instance to get.
    /// An instance of the specified type, or the default if no instance can be created.
    object GetInstance(Type type);

    /// 
    /// Gets all instances of the specified type.
    /// 
    /// The type of instance to get.
    /// An enumerable of available instances of the specified type.
    IEnumerable GetInstances();

    /// 
    /// Gets all instances of the specified type.
    /// 
    /// The type of instance to get.
    /// An enumerable of available instances of the specified type.
    IEnumerable GetInstances(Type type);

    /// 
    /// Gets the lifetime strategy for the specified type.
    /// 
    /// The type to get a lifetime strategy for.
    /// A  for the specified type.
    ILifetimeStrategy GetLifetimeStrategy(Type type);

    /// 
    /// Gets all lifetime strategies for the given type.
    /// 
    /// The type to get lifetime strategies for.
    /// An enumerable of lifetime strategies for the given type.
    IEnumerable GetLifetimeStrategies(Type type);

    /// 
    /// Creates a type registration for the specified type.
    /// 
    /// The type of instance to create a registration for.
    /// An  for the given type.
    IRegistration Register();

    /// 
    /// Registers a build strategy for the specified type.
    /// 
    /// The type to register a lifetime strategy for.
    /// The strategy used to create instances.
    void RegisterBuildStrategy(Type type, IBuildStrategy strategy);

    /// 
    /// Registers a lifetime strategy for the specified type.
    /// 
    /// The source type to register a lifetime strategy for.
    /// The target type to register a lifetime strategy for.
    /// The strategy used for lifetime management.
    void RegisterLifetimeStrategy(Type sourceType, Type targetType, ILifetimeStrategy strategy);
    #endregion
}

Ok, so we have the usual suspects…GetInstance, GetInstances, Register etc. If you’ve been exposed to other IoC containers, or even service locators, this should all be familiar. We then have methods like RegisterBuildStrategy, RegisterLifetimeStrategy. The real meat of the work for registering a type is done from the RegisterLifetimeStrategy method. It will create a binding between the source and target types, and the requested lifetime strategy.

The RegisterBuildStrategy is optional, it allows for a build strategy to be registered ahead of any types being resolved, this enables you to customise how your types are created. If no build strategy exists for a type being resolved, the target type will by analysed to figure out how it should be built and generate a build strategy for you.

How to configure

The one inescapable drawback of most IoC solutions is that it can be quite tedious to configure all the necessary components. This has been somewhat solved by approaches made by frameworks such as the Managed Extensibility Framework (MEF). MEF is all about composition and promotes type discovery ahead of configuration. I haven’t done any type discovery, so that means its back to configuration

This IoC design offers two ways to configure. Either using the configuration system, or fluently (that’s the buzzword, right?) in code. The configuration method allows you to configure multiple container setups in xml, which means if you wanted, you could have multiple container setups for different scenarios. Here is a sample configuration:

Relatively simple example, but you get the point. There are some niceties in the current version, it allows you to establish named types so you don’t have to put the full type names in each time, as well as supporting build and lifetime strategy declarations…that really needs some more work…

Getting fluent

Fluency has become a natural progression of programming design recently, and this model is no different. Let’s look at an example:

container.Register()
            .Using()
            .With(l => l.SomeProperty, "Hello World")
            .WithAppSetting(l => l.SomeOtherProperty, "SomeAppSettingKey");

With fluency, we get a very expressive way of configuring individual components. There are many ways we could expand on this, but you get the idea.

Where do we go from here

Who knows really, there was no real goal here, I didn’t set out to “create one IoC container to rule them all”, it was purely an experiment to see if I could do it. And so to that end, you’ll find the Visual Studio 2010 project (.NET 4.0 target) attached to the end of this blog post. Please, I welcome any feedback, if I’ve wasted my time doing this, it’s good to know. For those interested in IoC design, this could be a starting point. It’s certainly been a learning experience for me! Peace.

SimpleIoC

Integrating Regula with ASP.NET MVC and DataAnnotations

Matthew Abbott — Tue, 17 Aug 2010 19:49:23 +0000

Previously I discovered Regula, an annotation-based validation framework used for client-side validation of form elements. I wondered if it was possible to automatically wire up client-side validation using DataAnnotation’s ValidationAttributes on the server side, very similar to how xVal might handle it.

This is by no means usable, its really an experiment to see what is possible.

Resolving ValidationAttributes us Regula constraints

Right, first things first, we need some way of mapping between a ValidationAttribute, and its representation as a Regula constraint. To do this, we can create an interface contract which simply resolves an attribute as a constraint:

/// 
/// Defines the required contract for implementing a Regula attribute resolver.
/// 
public interface IAttributeResolver
{
    #region Methods
    /// 
    /// Resolves the specified attribute as a Regula constraint.
    /// 
    /// The attribute to resolve.
    /// The resolved constraint.
    string Resolve(ValidationAttribute attribute);
    #endregion
}

Next, we need to create a type resposible for calling these resolvers, so we’ve created the RegulaAdapter. This type will have a collection of registered resolvers that are mapped against attribute types:

/// 
/// Provides an adapter for translating validation attributes to Regula constraints.
/// 
/// The model type.
public class RegulaAdapter
{
    #region Fields
    private static readonly IDictionary Resolvers;
    #endregion

    #region Constructor
    /// 
    /// Statically initialises the  type.
    /// 
    static RegulaAdapter()
    {
        Resolvers = new Dictionary();
        RegisterDefaultResolvers();
    }
    #endregion

    #region Methods
    /// 
    /// Registers an attribute resolver for the specified attribute.
    /// 
    /// The type of attribute.
    /// The type of resolver.
    public static void RegisterResolver()
        where TAttribute : ValidationAttribute
        where TResolver: IAttributeResolver, new()
    {
        RegisterResolver(new TResolver());
    }

    /// 
    /// Registers an attribute resolver for the specified attribute.
    /// 
    /// The type of attribute.
    /// The type of resolver.
    /// The instance of resolver to register.
    public static void RegisterResolver(TResolver resolver)
        where TAttribute : ValidationAttribute
        where TResolver : IAttributeResolver
    {
        var type = typeof(TAttribute);

        if (Resolvers.ContainsKey(type))
            Resolvers[type] = resolver;
        else
            Resolvers.Add(type, resolver);
    }

    /// 
    /// Registers any default resolvers.
    /// 
    private static void RegisterDefaultResolvers()
    {
        RegisterResolver(new SimpleAttributeResolver("@Required"));
        RegisterResolver(new SimpleAttributeResolver("@Email"));
        RegisterResolver();
    }
    #endregion
}

We can provide some default resolvers, based on known validation attributes, e.g.:

/// 
/// Defines a simple attribute resolver.
/// 
public class SimpleAttributeResolver : IAttributeResolver
{
    #region Fields
    private readonly string Constraint;
    #endregion

    #region Constructor
    /// 
    /// Initialises a new instance of 
    /// 
    /// The constraint to return.
    public SimpleAttributeResolver(string constraint)
    {
        if (string.IsNullOrEmpty(constraint))
            throw new ArgumentException("'constraint' cannot be null or empty.");

        Constraint = constraint;
    }
    #endregion

    #region Methods
    /// 
    /// Resolves the specified attribute as a Regula constraint.
    /// 
    /// The attribute to resolve.
    /// The resolved constraint.
    public string Resolve(ValidationAttribute attribute)
    {
        return Constraint;
    }
    #endregion
}

/// 
/// Defines a simple attribute resolver.
/// 
public class RangeAttributeResolver : IAttributeResolver
{
    #region Methods
    /// 
    /// Resolves the specified attribute as a Regula constraint.
    /// 
    /// The attribute to resolve.
    /// The resolved constraint.
    public string Resolve(ValidationAttribute attribute)
    {
        var attr = attribute as RangeAttribute;
        if (attr == null)
            throw new InvalidOperationException("RangeAttributeResolver requires an instance of RangeAttribute");

        return string.Format("@Range(min={0}, max={1})", attr.Minimum, attr.Maximum);
    }
    #endregion
}

We can also create a custom attribute and map that to a resolver:

/// 
/// Validates a field against an email regular expression.
/// 
public class EmailAttribute : RegularExpressionAttribute
{
    #region Fields
    private const string RegexPattern = @"\b[A-Z0-9._%-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b";
    #endregion

    #region Constructor
    /// 
    /// Initialises a new instance of 
    /// 
    public EmailAttribute() : base(RegexPattern)
    { }
    #endregion
}

Wiring up client-side validation

To handle our client-side validation, we need some way of appending the Regula html attributes to standard controls. I haven’t found an easy way of doing this without writing a series of extension methods such as RegulaTextBoxFor(…) etc. This is only a first version, so I don’t really care at the moment…

Let’s finish off our implementation of our RegulaAdapter:

/// 
/// Provides an adapter for translating validation attributes to Regula constraints.
/// 
/// The model type.
public class RegulaAdapter
{
    #region Fields
    private static readonly IDictionary Resolvers;
    #endregion

    #region Constructor
    /// 
    /// Statically initialises the  type.
    /// 
    static RegulaAdapter()
    {
        Resolvers = new Dictionary();
        RegisterDefaultResolvers();
    }

    /// 
    /// Initialises a new instance of 
    /// 
    public RegulaAdapter()
    {
        ModelType = typeof(TModel);
    }
    #endregion

    #region Properties
    /// 
    /// Gets the model type.
    /// 
    public Type ModelType { get; private set; }
    #endregion

    #region Methods
    /// 
    /// Registers an attribute resolver for the specified attribute.
    /// 
    /// The type of attribute.
    /// The type of resolver.
    public static void RegisterResolver()
        where TAttribute : ValidationAttribute
        where TResolver: IAttributeResolver, new()
    {
        RegisterResolver(new TResolver());
    }

    /// 
    /// Registers an attribute resolver for the specified attribute.
    /// 
    /// The type of attribute.
    /// The type of resolver.
    /// The instance of resolver to register.
    public static void RegisterResolver(TResolver resolver)
        where TAttribute : ValidationAttribute
        where TResolver : IAttributeResolver
    {
        var type = typeof(TAttribute);

        if (Resolvers.ContainsKey(type))
            Resolvers[type] = resolver;
        else
            Resolvers.Add(type, resolver);
    }

    /// 
    /// Registers any default resolvers.
    /// 
    private static void RegisterDefaultResolvers()
    {
        RegisterResolver(new SimpleAttributeResolver("@Required"));
        RegisterResolver(new SimpleAttributeResolver("@Email"));
        RegisterResolver();
    }

    /// 
    /// Gets a dictionary of constraints for the specified type.
    /// 
    /// A dictionary of constraints for the specified type.
    public IEnumerable GetConstraints(string property = null)
    {
        var constraints = new List();

        var attributes = GetAttributes();
        if (!string.IsNullOrEmpty(property))
            attributes = attributes.Concat(GetAttributes(property));

        foreach (var attr in attributes)
        {
            Type type = attr.GetType();
            if (Resolvers.ContainsKey(type))
            {
                var resolver = Resolvers[type];
                constraints.Add(resolver.Resolve(attr));
            }
        }

        return constraints;
    }

    /// 
    /// Gets the attributes applied to the specified model.
    /// 
    /// An enumerable of validation attributes.
    private IEnumerable GetAttributes()
    {
        return ModelType
            .GetCustomAttributes(typeof(ValidationAttribute), true)
            .Cast();
    }

    /// 
    /// Gets the attributes applied to the specified property.
    /// 
    /// An enumerable of validation attributes.
    private IEnumerable GetAttributes(string property)
    {
        return ModelType
            .GetProperty(property)
            .GetCustomAttributes(typeof(ValidationAttribute), true)
            .Cast();
    }
    #endregion
}

With that, we can now add a HtmlHelper extension method that will create our textbox:

/// 
/// Provides html helper extensions used to create html controls with Regula validation.
/// 
public static class RegulaExtensions
{
    #region Methods
    /// 
    /// Creates a textbox for the specified expression that supports Regula validation.
    /// 
    /// The model type.
    /// The property type.
    /// The html helper used to generate the control.
    /// The expression used to identify the property to create the control for.
    /// The collection of html attributes to render to the client.
    /// The string representation of the textbox.
    public static MvcHtmlString RegulaTextBoxFor
        (this HtmlHelper htmlHelper, Expression> expression, IDictionary htmlAttributes)
    {
        if (htmlAttributes == null)
        {
            htmlAttributes = new Dictionary { { "class", "regula-validation" } };
        }
        else
        {
            if (htmlAttributes.ContainsKey("class"))
                htmlAttributes["class"] = string.Join(" ", htmlAttributes["class"] as string, "regula-validation");
            else
                htmlAttributes.Add("class", "regula-validation");
        }

        var adapter = new RegulaAdapter();
        var member = expression.Body as MemberExpression;
        string name = member == null ? null : member.Member.Name;

        var constraints = adapter.GetConstraints(name);
        htmlAttributes.Add("data-constraints", string.Join(" ", constraints));

        return htmlHelper.TextBoxFor(expression, htmlAttributes);
    }

    /// 
    /// Creates a textbox for the specified expression that supports Regula validation.
    /// 
    /// The model type.
    /// The property type.
    /// The html helper used to generate the control.
    /// The expression used to identify the property to create the control for.
    /// The object that represents the collection of html attributes.
    /// The string representation of the textbox.
    public static MvcHtmlString RegulaTextBoxFor
        (this HtmlHelper htmlHelper, Expression> expression, object htmlAttributes)
    {
        return RegulaTextBoxFor(htmlHelper, expression, new RouteValueDictionary(htmlAttributes));
    }

    /// 
    /// Creates a textbox for the specified expression that supports Regula validation.
    /// 
    /// The model type.
    /// The property type.
    /// The html helper used to generate the control.
    /// The expression used to identify the property to create the control for.
    /// The string representation of the textbox.
    public static MvcHtmlString RegulaTextBoxFor
        (this HtmlHelper htmlHelper, Expression> expression)
    {
        return RegulaTextBoxFor(htmlHelper, expression, null);
    }
    #endregion
}

Example Model with Client-side Validation

As an example, we’ll modify the stock ASP.NET MVC project. Let’s create an example model:

public class Person
{
    #region Properties
    [Required]
    public string Name { get; set; }

    [Email]
    public string Email { get; set; }

    [Range(0, 120)]
    public int Age { get; set; }
    #endregion
}

By passing a dummy instance to our view, we can express the validation using something similar to:




<%: ViewData["Message"] %>

    To learn more about ASP.NET MVC visit http://asp.net/mvc.

<% Html.BeginForm("Index", "Home", FormMethod.Post, new { id = "myForm" }); %>

    <%= Html.RegulaTextBoxFor(m => m.Name) %>


    <%= Html.RegulaTextBoxFor(m => m.Email) %>


    <%= Html.RegulaTextBoxFor(m => m.Age) %>


<% Html.EndForm(); %>

Which should generate the following html markup:

Welcome to ASP.NET MVC!

To learn more about ASP.NET MVC visit http://asp.net/mvc.

As I said, it is possible, and it also makes me wonder if this could be adapted to work with something like xVal? Who knows! Please find the example project attached…

RegulaMVC

Regula as a jQuery Plugin

Matthew Abbott — Fri, 13 Aug 2010 22:00:16 +0000

Earlier this evening I came across a Stack Overflow question regarding a most excellent new javascript validation framework, called Regula. Regula is an annotation-based validation framework that hides the complexities of binding complex validation events to controls by extending the DOM element itself with annotations about how it should be validated. Here is a quick example:

In the above example, im forcing that textbox to validate against two constraints, a @NotEmpty constraint, and an @Email constraint, both of which are quite self-explanatory. Although I’ve only just started looking at it, it does look very promising, offering an array of built-in constraints, as well as the ability to quickly add your own, allowing you to easily reuse constraints on multiple fields across multiple pages.

One thing I quickly wanted to add in though, as a way to use Regula as a jQuery plugin, and thus I added the following to the Regula source:

if (jQuery) {
    (function($)
    {
        $.regula = function(formId, callback) {
            regula.bind();

            $("#" + formId).submit(function() {
                var validationResults = regula.validate();

                if (validationResults.length > 0)
                {
                    if (callback)
                        callback(validationResults);

                    return false;
                }

                return true;
            });
        };
    })(jQuery);
}

Now we can easily call:

$(function()
{
    $.regula("myForm", function(results)
    {
        // Do something with validation results here.
    });
});

This greatly simplifies the binding of the validation controls to the form, and gives us an optional callback for when validation fails.

Please visit Vivin Paliath’s blog for more information

Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part Three

Matthew Abbott — Fri, 16 Jul 2010 10:20:56 +0000

See also: Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part One
See also: Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part Two
Currently reading: Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part Three

Firstly, sorry it’s been so long since my last MVC+MEF post, been a bit busy with life in general. Still haven’t managed to get my project onto CodePlex, but we shall see soon!

Ok, so where did we get to last time? We’ve managed to build a prototype MVC+MEF framework that supports modular areas and strongly-typed views. A couple of readers have been asking how we can incorporate IoC into our framework, and the question is really: do we need to?

This framework was originally conceived as a starting point for building a web application, so we could essentially allow MEF do handle our DI for us. But its not often the case that we can simply start a new project, but build off an existing project, and to go one stage further, if you have a lot of your existing code infrastructure built around an existing IoC container, then you really need to expose that existing infrastructure to your website.

The good news is there is a way, and it’s rather easy. Glenn Block (everyone’s favourite MEF guy) pointed me to a rather interesting project, called the Common Services Locator, you can find it on CodePlex here.

The CSL project is geared to providing a common abstraction over service location (i.e. accessing and instantiating types, regardless of which third-party IoC container you are using). As long as they provide a CSL provider, we can leverage them relatively easily with out MEF+MVC framework.

So this blog post is essentially going to cover the integration of an IoC container (actually, 2, just to demonstrate how easy it is) into our framework. But before we can do that, we really need to look at refactoring bits of our code. Let’s begin with composition.

Refactoring Composition

In the previous version of the framework, we had all composition taking place within our Application class. This locks both the CompositionContainer, and its associated Catalogs and ExportProviders, hiding them away from the public. If you want to leverage composition in another part of your site, it was exactly easy. So, in steps our new Composer class. This essentially is a wrapper around all the composition functionality of the project, and is something we can easily pass round. Let’s have a look:

/// 
/// Provides a common mechanism for composing parts.
/// 
public class Composer : IComposer
{
  //
}

The Composer wraps up the management of the container, as well as adding any catalogs and export providers. This allows us to easily re-build the catalog as and when we need. When we want to composer a singular instance, we can easily do:

/// 
/// Composes the specified object.
/// 
/// The object to be composed.
public void Compose(object @object)
{
    if (@object == null)
        throw new ArgumentNullException("object");

    if (Catalog == null)
        return;

    EnsureContainer();
    Container.ComposeParts(@object);
}

/// 
/// Ensures the Container has been instantiated/re-instantiated if the Composer has been modified.
/// 
private void EnsureContainer()
{
    if (modified || Container == null)
    {
        if (Container != null)
            Container.Dispose();

        Container = new CompositionContainer(Catalog, ExportProviders.ToArray());

        foreach (var provider in postContainerModifiers.Keys)
            postContainerModifiers[provider](provider, Container);

        if (ExportSelf)
        {
            var batch = new CompositionBatch();
            batch.AddExportedValue(this);
            Container.Compose(batch);
        }

        modified = false;
    }
}

I’ve added an interface, IComposer, which provides a contract by which we can export the Composer itself. This may be useful in scenarios where you want to resolve type instances manually witout worrying about MEF itself. Because of this, the terminology I’ve used for the interface is much more akin to an IoC container, so methods like Resolve and ResolveAll are exposed here. You could then import/inject an instance of the composer if you wanted to:

[ImportingConstructor]
public MyType(IComposer composer) {
  var instance = composer.Resolve();
}

Although really, if you know what types your going to be using, you could just inject them directly instead of using the composer.

We’ve had to refactor the Application class itself to now support the Composer, luckily this wasn’t a lot of work:

#region Properties
/// 
/// Gets the  used to compose parts.
/// 
public static Composer Composer { get; private set; }
#endregion

#region Methods
/// 
/// The start method of the application.
/// 
protected void Application_Start()
{
    // Perform any tasks required before composition.
    PreCompose();

    // Create the composer used for composition.
    Composer = CreateComposer();

    // Compose the application.
    Compose();

    // Set the controller factory.
    ControllerBuilder.Current.SetControllerFactory(ControllerFactory);

    // Set the view engine that supports imported areas.
    ViewEngines.Engines.Add(new AreaViewEngine());

    // Initialises the application.
    Initialise();

    // Register MVC routes.
    RegisterRoutes();
}

/// 
/// Creates a  used to compose parts.
/// 
/// 
protected virtual Composer CreateComposer()
{
    var composer = new Composer();

    GetDirectoryCatalogs()
        .ForEach(composer.AddCatalog);

    composer.AddExportProvider(
        new DynamicInstantiationExportProvider(),
        (provider, container) => ((DynamicInstantiationExportProvider)provider).SourceProvider = container);

    return composer;
}

We once again make the CreateComposer method virtual, so if you do want exact control of how the Composer is created, possibly to wire up additional export providers/catalogs etc, you can override this and do what you want.

Refactoring Exports

Currently we manage our exports through a combination of the ExportAttribute and the ExportMetadataAttribute types. This is great, its easy, but does lead to problems, particularly when metadata is missing this is required for composition. This is important, as MEF will not compose types which do not satisfy the required import definitions. Consider our Controller type, currently we see this:

[Export(typeof(IController)), ExportMetadata("Name", "Blog")]
public BlogController: Controller
{

}

If we forget the ExportMetadataAttribute attribute, the controller will not be composed. What we really need to do, is ensure that the controller metadata is passed with the export. We can create a custom export attribute which provides this metadata:

/// 
/// Exports a controller.
/// 
[MetadataAttribute, AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
public class ExportControllerAttribute : ExportAttribute, IControllerMetadata
{
    #region Constructor
    /// 
    /// Initialises a new instance of the  class.
    /// 
    /// The name of the controller.
    public ExportControllerAttribute(string name) : base(typeof(IController))
    {
        if (string.IsNullOrEmpty(name))
            throw new ArgumentException("Controller name cannot be null or empty.");

        this.Name = name;
    }
    #endregion

    #region Properties
    /// 
    /// Gets the name of the controller.
    /// 
    public string Name { get; private set; }
    #endregion
}

This export attribute ensures that we have the controller name alongside the export. One thing to note, is you don’t actually have to decorate this type with your metadata interface, MEF will project the required properties for you, but I like to do so, as I know it ensures that my export attribute is conforming to my required metadata interface.

Now, we can simply our export:

[ExportController("Blog")]
public BlogController: Controller
{

}

Integrating Unity into MEF+MVC

Ok, finally onto what we really want to do, IoC integration . To add support for Unity (and any compatible CSL provider, I’ve added a bit of code supplied by Mr. Block, the CSLExportProvider (read: Glenn’s code). We can augment this ExportProvider into our Composer, and then wire up our Unity container:

public class MvcApplication : Application
{
    #region Fields
    private IUnityContainer unityContainer;
    private CSLExportProvider exportProvider;
    #endregion

    #region Methods
    /// 
    /// Creates the instance of the Unity container.
    /// 
    protected override void PreCompose()
    {
        unityContainer = new UnityContainer();

        var locator = new UnityServiceLocator(unityContainer);
        exportProvider = new CSLExportProvider(locator);

        unityContainer.AddExtension(new CSLExportProviderExtension(exportProvider));

        RegisterTypes();
    }

    /// 
    /// Registers any required types for the Unity container.
    /// 
    protected void RegisterTypes()
    {
        unityContainer.RegisterType();
    }

    /// 
    /// Creates the composer used for composition.
    /// 
    /// 
    protected override MefMvcFramework.Composition.Composer CreateComposer()
    {
        var composer = base.CreateComposer();
        composer.AddExportProvider(exportProvider);

        return composer;
    }
    #endregion
}

In the example above, we are taking advantage of our Application class design to control how the Composer is constructed in relation to our IoC Container, Unity. We are then registering a simple example type, the ITicketSystem. Because we’ve registered this type with Unity, thanks to the Common Services Locator provider, we can now access these when importing/injecting into our target types. Let’s create a new MVC Controller to demonstrate this:

[ExportController("Support")]
public class SupportController : Controller
{
    #region Fields
    private ITicketSystem ticketSystem;
    #endregion

    #region Constructor
    [ImportingConstructor]
    public SupportController(ITicketSystem ticketSystem)
    {
        this.ticketSystem = ticketSystem;
    }
    #endregion

    #region Actions
    public ActionResult Index()
    {
        var ticket = ticketSystem.CreateTicket();
        return Content(ticket.Title);
    }
    #endregion
}

With our new controller, when we create an instance, we inject our ITicketSystem instance through the constructor. The important thing here, is that our instance of ITicketSystem is provided by our IoC container (currently Unity), exposed via MEF. Thus demonstrates just how flexible and robust MEF really is.

We can even do it for another IoC container, let’s try Autofac:

public class MvcApplication : Application
{
  #region Fields
  private CSLExportProvider exportProvider;
  #endregion

  #region Methods
  /// 
  /// Creates the instance of the Unity container.
  /// 
  protected override void PreCompose()
  {
      var container = new ContainerBuilder().Build();
      exportProvider = new CSLExportProvider(new AutofacServiceLocator(container));

      RegisterTypes(container);
  }

  /// 
  /// Registers any types required for the container.
  /// 
  /// The container.
  private void RegisterTypes(IContainer container)
  {
      var builder = new ContainerBuilder();

      builder.RegisterType().As();
      exportProvider.RegisterType(typeof(ITicketSystem));

      builder.Update(container);
  }

  /// 
  /// Creates the composer used for composition.
  /// 
  /// 
  protected override MefMvcFramework.Composition.Composer CreateComposer()
  {
      var composer = base.CreateComposer();
      composer.AddExportProvider(exportProvider);

      return composer;
  }
  #endregion
}

Minimal code change makes me very happy! Any CSL compatible provider can be used, allowing enormous flexibility and integration options. Hope you like it!

Download VS2010 Project

UPDATE For Martyn: wiring up Castle Windsor was really easy, in fact took my only a few minutes to wire it up and add a component to the container. This is again thanks to the CSL project, whereby you can grab a CSL-provider for Castle Windsor.

The code change is as follows:

namespace MefMvcApplication
{
    using Castle.Windsor;
    using CommonServiceLocator.WindsorAdapter;

    using MefMvcFramework.Example.TicketSystem;
    using MefMvcFramework.ServiceLocation;
    using MefMvcFramework.Web;

    public class MvcApplication : Application
    {
        #region Fields
        private CSLExportProvider exportProvider;
        #endregion

        #region Methods
        /// 
        /// Creates the instance of the Unity container.
        /// 
        protected override void PreCompose()
        {
            var container = new WindsorContainer();
            exportProvider = new CSLExportProvider(new WindsorServiceLocator(container));

            RegisterTypes(container);
        }

        /// 
        /// Registers any types required for the container.
        /// 
        /// The container.
        private void RegisterTypes(IWindsorContainer container)
        {
            container.AddComponent("TicketSystem", typeof(ITicketSystem), typeof(SimpleTicketSystem));
            exportProvider.RegisterType(typeof(ITicketSystem));
        }

        /// 
        /// Creates the composer used for composition.
        /// 
        /// 
        protected override MefMvcFramework.Composition.Composer CreateComposer()
        {
            var composer = base.CreateComposer();
            composer.AddExportProvider(exportProvider);

            return composer;
        }
        #endregion
    }
}

The Castle Windsor variant of the project is attached. Hope that helps.

Download VS 2010 Project (Castle Windsor)

Javascript Linq Extensions

Matthew Abbott — Fri, 25 Jun 2010 08:49:42 +0000

I love Linq. Linq just makes code awesome. Well, that’s my view on it anyway. I also like Javascript, and through libraries like JQuery we’ve now got a framework whereby you can pretty much do anything, but often I like getting down to the bare-bones of Javascript and just having a go at what it can do.

One of the great things about Javascript objects is that they are so easy to extend. This is due to the prototyping nature of the language itself. Recently on my journey on Stack Overflow (~1200 in 22 days!) a question was asked about searching through a javascript array for a specific item. Of course we could easily do something like this:

for (var i = 0; i < arrayObj.length; i++) { ... }

...etc, but I remembered a while ago I had written some very cool Linq-esque style extension methods to Javascript array object. Methods like Where, Select, etc, here's an example of my Where method:

Array.prototype.Where = function(predicate) {
    Throw.IfArgumentNull(predicate, "predicate");
    Throw.IfNotAFunction(predicate, "predicate");

    var results = new Array();
    for (var i = 0; i < this.length; i++) {
        var item = this[i];
        if (predicate(item))
            results.push(item);
    }

    return results;
};

Given that, I could do something like so:

  Person = function(name, age, likes) {
    this.Name = name;
    this.Age = age;
    this.Likes = likes;
  };

  var people = [
    new Person("Doug", 20, "Bananas"),
    new Person("Jeff", 21, "Apples"),
    new Person("Richard", 22, "Oranges"),
    new Person("Bonzo", 50, "Bananas")
  ];

  var peopleWhoLikeBananas = people.Where(function(p) {
    return (p.Likes == "Bananas"); });

Pretty cool eh? If you're familiar with the Linq extension methods, you should be at home here too!

I also decided to extend the base Object class itself, providing some Equals and CompareTo methods that act as default equality and comparer methods:

Object.Equals = function(objA, objB) {
    if (objA != null)
        return objA.Equals(objB);

    if (objB != null)
        return objB.Equals(objA);

    return false;
};

Object.prototype.CompareTo = function(object) {
    if (this < object)
        return -1;

    if (this > object)
        return 1;

    return 0;
};

Object.prototype.Equals = function(object) {
    return (this == object);
};

Also included in the attached zip is my prototype Javascript testing framework and also the micro-mocking framework I blogged about previously, it's nothing special and nowhere near production code:

Attached in a zip of all the bits and bobs, its nothing formal and it's not production code, do with it what you will. I appreciate any feedback too.

Javascript-Linq-Extensions

Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part Two

Matthew Abbott — Mon, 07 Jun 2010 13:24:25 +0000

See also: Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part One
Currently reading: Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part Two
See also: Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part Three

In my previous post I presented an MVC Framework that uses the Managed Extensibility Framework (MEF) to allow for powerful extensibility of ASP.NET MVC, not just for controllers, but also for views. You can find my original article here.

There are a couple of small issues I want to iron out before it becomes a project-quality framework. These issues are:

Strongly-typed Models from imported libraries
Managing referenced libraries in built modules

Strongly-typed Models from imported libraries

In the previous version of the framework, one thing which I had neglected to highlight and test is using a strongly-typed view model from an external module. This action turned out to be a bigger issue than simply trying to find a reference. The first exception that was thrown at me was this:

This is quite a common occurence, and is due to the MVC framework not being able to instantiate the types required to process the views. Because our views sit outside the the /Views folder, the /Views specific configuration items were missing from the config. We can easily add these in to our main web.config file:

Ok, thats done, what next:

This one was a little more confusing, it can’t find my type? How comes my Controller can but my View can’t? In current WebForms technology (including ASP.NET WebForms) our pages are compiled into a seperate assembly, referenced to the main website. Because we’ve imported our types using MEF, we haven’t created a reference to the specific assemblies, so no reference is created to the page assemblies which are generated. There is another issue here also, our imported assemblies don’t sit in the /bin folder of the application, so discovering the correct assemblies requires a little work. Firstly, we need to modify our Application class, changing it’s CreateCompositionContainer method to fire a call to another method which registers our path for probing.

  /// 
  /// Creates the composition container.
  /// 
  /// 
  protected virtual CompositionContainer CreateCompositionContainer()
  {
      var catalog = new AggregateCatalog();
      catalog.Catalogs.Add(new DirectoryCatalog(MapPath("~/bin")));

      var config = CompositionConfigurationSection.GetInstance();
      if (config != null && config.Catalogs != null) {
          config.Catalogs
              .Cast()
              .ForEach(c =>
              {
                  if (!string.IsNullOrEmpty(c.Path)) {
                      string path = c.Path;
                      if (path.StartsWith("~"))
                          path = MapPath(path);

                      foreach (var directoryCatalog in GetDirectoryCatalogs(path)) {

                          // Register our path for probing.
                          RegisterPath(directoryCatalog.FullPath);

                          // Add the catalog.
                          catalog.Catalogs.Add(directoryCatalog);
                      }
                  }
              });
      }

      var provider = new DynamicInstantiationExportProvider();
      var container = new CompositionContainer(catalog, provider);
      provider.SourceProvider = container;

      return container;
  }

Here is our method, RegisterPath:

  /// 
  /// Registers the specified path for probing.
  /// 
  /// The probable path.
  private void RegisterPath(string path)
  {
      AppDomain.CurrentDomain.AppendPrivatePath(path);
  }

Ok, it’s not much, but what it is doing is appending each path for our DirectoryCatalog instances into the private path of the AppDomain. Through the type resolution process, the AppDomain will probe the private paths to try and find the required types, if its not GAC’d or previously found.

We’re nearly there, but now we need to make a final change to our views. We need to add in a command to the top of each view, pointing to the assembly which should be referenced for the view. In this example, I’ve added the MefMvcFramework.Blog assembly as the referenced one:

  <%@ Assembly Name="MefMvcFramework.Blog" %>
  <%@ Import Namespace="MefMvcFramework.Blog.Models" %>
  <%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %>
  
      <%: Model.Title %>

Let’s run that, and it now works

Managing referenced libraries in built modules

It’s been noted that when we build a module that has references of it’s own, the default build action for references is to copy any non-GAC’d references to the output directory of the application. Commonly with shared functionality you’d put your support assemblies in the /bin folder and our modules will still be able to run correctly. For these shared assemblies, we can tell Visual Studio not to deploy them alongside our built modules, we do this by changing the CopyLocal properties of referenced assemblies.

In Visual Studio, select the reference in the solution explorer \References\, and select Properties with the context menu (or press F4):

Set the CopyLocal property to false, this will stop Visual Studio from deploying the referenced assemblies.

To see the effect, empty the /Areas/Blog folder of your main application, and rebuild, you should see a much cleaner number of files:

What’s next? I’d like to investigate dependency injection for Controllers, either through MEF alone, or possibly mixing it up with an IoC container, if required. Watch this space

Download VS2010 Project (fixed)

Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part One

Matthew Abbott — Thu, 06 May 2010 17:12:28 +0000

Currently reading: Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part One
See also: Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part Two
See also: Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part Three

Building on the work I have done previous (see Using MEF with MVC Controllers), I’ve created a revised architecture of MEF + MVC using .NET 4.0. I’m (mostly) happy with the outcome.

One of the things I wanted to get right, was allowing true modularity using MEF. As you already know, its now relatively painless to do modular code with ASP.NET (thanks to standard .NET activation, or using something like MEF for automatic composition), but one of the challenges is not how the code plugs in, but the views themselves. This was always difficult with WebForms because of the way the .aspx pages are compiled (seperately from the code). The other pain is the way you may have had to organise your files in the file system, they were also disconnected from the libraries because these had to exist in the \bin directory of your application.

Extensible MVC with MEF can address these:

a) Libraries used with MEF catalogs can be in any directory accessible by the application, and
b) Routes do not use filenames, so the location of your .aspx views doesn’t matter (as long as MVC can access them).

So, how do we go about making a truly modular MVC implementation? We start with what something similar to before, so lets build a base implementation. This has evolved a bit since my early version, namely the application work is now in a seperate assembly, MefMvcFramework.

public class Application : HttpApplication {

Within this application, we declare our two imports:

  [ImportMany] private IEnumerable> RouteRegistrars;
  [Import] private ImportControllerFactory ControllerFactory;

Our IRouteRegistrar instances allow us to dynamically register our routes, and our ImportControllerFactory handles the creation of controller instances used by MVC. I’ve switched to using Lazy<,> for the registrars as we don’t really need to use a PartFactory<,> (read: PartCreator<,>) instance to manage the dynamic instantiation of instances, there is no need for it, Lazy<,> allows us to access our metadata without the overhead of dynamic instantiation. Also, PartFactory<,> is geared to creating new instances, whereas Lazy<,> persists a single instance, using lazy loading.

Next, let’s flesh out our Application_Start() method:

  protected void Application_Start()
  {
      // Perform any tasks required before composition.
      PreCompose();

      // Compose the application.
      Compose();

      // Set the controller factory.
      ControllerBuilder.Current.SetControllerFactory(ControllerFactory);

      // Set the view engine that supports imported areas.
      ViewEngines.Engines.Add(new AreaViewEngine());

      // Initialises the application.
      Initialise();

      // Register MVC routes.
      RegisterRoutes();
  }

I’ve added additional extension points to the application start method as it allows us finer control over how our application is being initialised in relation to composition. PreCompose(), Compose(), Initialise() and RegisterRoutes() are virtual methods, so we can optional override them in our specific implementation. They’re all pretty self-explanitory, so I won’t go through what each of them does.

What you will notice though, is that I’ve added a custom ViewEngine. This is to allow us to use custom locations for our views. I haven’t built anything particularly special, we just override the view location formats in the constructor:

public class AreaViewEngine : WebFormViewEngine
{
    #region Constructor
    /// 
    /// Initialises a new instance of .
    /// 
    public AreaViewEngine()
    {
        MasterLocationFormats = new[]
                                {
                                    "~/Areas/{1}/Views/{0}.master",
                                    "~/Views/{1}/{0}.master",
                                    "~/Views/Shared/{0}.master"
                                };

        ViewLocationFormats = new[]
                                {
                                    "~/Areas/{1}/Views/{0}.aspx",
                                    "~/Views/{1}/{0}.aspx",
                                    "~/Views/Shared/{0}.aspx"
                                };

        AreaPartialViewLocationFormats = new[]
                                {
                                    "~/Areas/{1}/Views/{0}.ascx",
                                    "~/Views/{1}/{0}.ascx",
                                    "~/Views/Shared/{0}.ascx"
                                };
    }
    #endregion
}

With this view engine, I’m instructing MVC to look in \Areas for our view content, or more specifically \Areas\<>\ for the content, i.e, if I created a BlogController, it can now look in \Areas\Blog\ for views as well as the standard views.

My project structure now looks as such:

I haven’t done anything specific to the ASP.NET MVC 2 Application project yet, I’ve simply added a required Areas folder (make sure you do this!), and changed our global application class, it’s now much leaner:

using MefMvcFramework.Web;

public class MvcApplication : Application
{
    #region Methods
    /// 
    /// Initialises the application.
    /// 
    protected override void Initialise()
    {

    }
    #endregion
}

I like that. Because the application class is seperate, we can re-use it in multiple web projects, with minimal implementation in the specific web projects that use it. You’ll notice there is no default route registration, thats because we now take advantage of MEF with our application, we make an instance of IRouteRegistrar for our default routes:

[Export(typeof(IRouteRegistrar)), ExportMetadata("Order", 100)]
public class DefaultRouteRegistrar : IRouteRegistrar
{
    #region Methods
    /// 
    /// Registers any routes to be ignored by the routing system.
    /// 
    /// The collection of routes to add to.
    public void RegisterIgnoreRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
        routes.IgnoreRoute("{resource}.ico/{*pathInfo}");
    }

    /// 
    /// Registers any routes to be used by the routing system.
    /// 
    /// The collection of routes to add to.
    public void RegisterRoutes(RouteCollection routes)
    {
        routes.MapRoute("Default", "{controller}/{action}", new { controller = "Home", action = "Index" });
    }
    #endregion
}

If you ensure that is done, we should be able to run the application and get our (now familiar) bland ASP.NET MVC example site. Next though, it’s time to add a new area. We going to do this by adding a new project to the solution, and changing some specifics of how it is building/outputting files. Although this won’t matter for production (you’ll hopefully have a much finer control of the build process), it does show how we can easily drop in a new module without having to recompile the main website. I’ve created a solution folder \Areas and added a new project, MefMvcFramework.Blog with a few files, here is my new project structure:

What we want, is to change the output location of the project to be in the areas folder of the main website, so open up the project properties, selet the Build tab and change the output path (do this for All Configurations, not just Debug), and change the output to be the \Areas\Blog folder of the main website.

We also need to instruct the views to be copied to the output, so select any views, and goto the Properties window, and change the Copy to Output property to Copy if newer. This means when we build the application, the Index.aspx view should end up at \Areas\Blog\Views\Index.aspx.

Right then, on to the controller, it’s not doing anything fancy, just showing us the default view:

[Export(typeof(IController)), ExportMetadata("Name", "Blog")]
public class BlogController : Controller
{
    #region Actions
    /// 
    /// Displays the blog index.
    /// 
    public ActionResult Index()
    {
        return View();
    }
    #endregion
}

Hopefully, building the solution and running should demonstrate that the BlogController has been loaded dynamically though MEF and is handling any requests for route /Blog. If you run this url, you should see something like:

That’s awesome, we now have a completely modular framework for ASP.NET MVC thanks to MEF. But wait, I want to go one step further. What I want to achieve is automatically adding a blog link to the navigation. Now we shouldn’t hard code this in the page, because the Blog module might not be available. What we can do is add it through the concept of verbs. So I’ve created an interface:

public interface IActionVerb
{
    #region Properties
    /// 
    /// Gets the name of the verb.
    /// 
    string Name { get; }

    /// 
    /// Gets the action.
    /// 
    string Action { get; }

    /// 
    /// Gets the controller.
    /// 
    string Controller { get; }
    #endregion
}

Now, what I’m going to do with that, is allow MEF to automatically import verbs, and we can then grab them based on category, so here is a sample verb I’ve added for the Blog:

[Export(typeof(IActionVerb)), ExportMetadata("Category", "Navigation")]
public class BlogVerb : IActionVerb
{
    #region Properties
    /// 
    /// Gets the name.
    /// 
    public string Name
    {
        get { return "My Blog"; }
    } 

    /// 
    /// Gets the action.
    /// 
    public string Action
    {
        get { return "Index"; }
    }

    /// 
    /// Gets the controller.
    /// 
    public string Controller
    {
        get { return "Blog"; }
    }
    #endregion
}

We’re going to be mapping verbs to actions on controllers, so let’s make some changes to our application class, by adding a static field:

  private static IEnumerable> ActionVerbs;

Now, MEF can’t compose static instances, and unfortunately we can’t rely on an instance member either, as an instance of the application class is created with each request (but the Application_Start() method is only executed once for the lifetime of the web application). So what do we do? We create the static field, but don’t mark it as an import, instead, we can manually assign to this field during composition:

  protected virtual void Compose()
  {
      var container = CreateCompositionContainer();
      if (container == null)
          return;

      container.ComposeParts(this);
      ActionVerbs = container.GetExports();
  }

Thats the important part done, now lets modify the default view files to support this, firstly, let’s change our MasterPage:

  <%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

  
  
  
      <asp:ContentPlaceHolder ID="TitleContent" runat="server" />
      
  

  
      

          
              
                  My MVC Application
              

              
                  <% Html.RenderPartial("LogOnUserControl"); %>
               

              <% Html.RenderPartial("NavigationItems"); %>

I’ve taken out the original menu, and added a RenderPartial instruction, which accepts our NavigationItems.ascx view, which we’ll go ahead and create now:

  <%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
  <%@ Import Namespace="MefMvcApplication" %>
  

      
          <%: Html.ActionLink("Home", "Index", "Home")%>
          <%: Html.ActionLink("About", "About", "Home")%>
          <% foreach (var verb in MvcApplication.GetVerbsForCategory("Navigation")) { %>
              <%: Html.ActionLink(verb.Name, verb.Action, verb.Controller)%>
          <% } %>

But how do we get to our verbs? We need to add another method to our application class, GetVerbsForCategory(string):

  public static IEnumerable GetVerbsForCategory(string category)
  {
      Throw.IfArgumentNullOrEmpty(category, "category");

      return ActionVerbs
          .Where(l => l.Metadata.Category.Equals(category, StringComparison.InvariantCultureIgnoreCase))
          .Select(l => l.Value);
  }

And that should be it! Run the application again, you should see a My Blog link in the navigation, all handled dynamically!

There are still a few things I might try and work out, but I am now quite satisfied with this implementation. You can pull the Blog module out of the system and it will simply not be loaded when the application restarts. We can now also dynamically update our modules without worrying about our parent ASP.NET MVC application. I hope you enjoy it, let me know what you think.

Download VS2010 Project

Burned my Feed

Matthew Abbott — Tue, 13 Apr 2010 06:44:51 +0000

Moved RSS Feed Management over to FeedBurner so I can better track stats and get a general feel of how my blog content is being consumed. New feed URL: http://feeds.feedburner.com/FidelityDesign

Mocking in Javascript

Matthew Abbott — Thu, 08 Apr 2010 07:17:18 +0000

While I do most of my coding in C#, there is still a lot of work I do which resides in the client, namely the browser. While we can employ nice unit testing and mocking frameworks in C#, the same can’t be said for Javascript. There has been a large uptake of Javascript frameworks in these recent years, such as the quite awesome JQuery library. With such a large move into client-side development, it becomes necessary to expand on the tools available for this development platform.

I’ve been introduced to Moq in C#, which I find to be easy to pick up and has a nice syntax. Generally when mocking an interface, we can simply do:

  public interface ICalculatorService
  {
    int Add(int operandA, int operandB);
  }

  var mock = new Mock();
  mock.Setup(c => c.Add(It.IsAny(), It.IsAny())).Returns(100);

  int result = mock.Object.Add(1, 2); // Will return 100.

In the above example, I’m simply telling the Moq framework that when the Add method is called on the mocked interface, with any integer for both operands, then return 100. This simple syntax makes writing mocks relatively painless. I wondered if this could also be done in Javascript.

What I set out to do, is create a simple mocking framework in Javascript which behaves similarly to Moq.

As Javascript has no concept of interfaces and contract based programming, we can mimick this ability using a javascript object. If we can imagine this following as a pseudo interface:

  var ICalculatorService = {
    Add: function() {}
  };

To be able to handle the binding betwen the mocked object and it’s associated members, we can create a type called a MockBinding:

var MockBinding = function(name, member, args) {
    this.Name = name;
    this.Member = member;
    this.Arguments = args;
};
MockBinding.prototype = {
    Satisfies: function(args) {
        if (typeof(this.Arguments) == "undefined") return true;
        if (this.Arguments == null && args == null) return true;
        if (this.Arguments == null || args == null) return false;
        if (this.Arguments.length != args.length) return false;

        for (var i = 0; i < this.Arguments.length; i++) {
            var argA = this.Arguments[i];
            var argB = args[i];

            var typeA = typeof(argA);
            var typeB = typeof(argB);

            if (typeA == typeB && argA == argB) continue;
            if (argA == Is.AnyString && typeB == "string") continue;
            if (argA == Is.AnyNumber && typeB == "number") continue;
            if (argA == Is.AnyObject && typeB == "object") continue;
            if (argA == Is.AnyFunction && typeB == "function") continue;
            if (argA == Is.Undefined && typeB == "undefined") continue;
            return false;
        }
        return true;
    }
};

With this binding, we can create properties for the name (this is the name of the member), the value of the member, and arguments (where the member is a function). We also add in a method which allows us to compare a set of arguments to see if the current binding would satisfy those bindings. The Satisfies method will firstly check the obvious things, undefined, nulls, array lengths. If that all passes, we can then check the argument types. I've defined an enumeration (of sorts):

var Is = {
    AnyString: "@any-string",
    AnyNumber: "@any-number",
    AnyObject: "@any-object",
    AnyFunction: "@any-function",
    Undefined: "@undefined"
};

There is no real reason behind the values, they could be anything, numbers, etc.

Next, I defined a utility class for creating the actual mocked object:

var MockUtility = {};
MockUtility._emptyFunction = function() { };
MockUtility.CreateMockedObject = function(graph) {
    var object = {};
    for (var member in graph) {
        var type = typeof(graph[member]);
        if (type == "string" || type == "object") object[member] = null;
        else if (type == "number") object[member] = 0;
        else if (type == "function") object[member] = MockUtility._emptyFunction;
        else object[member] = null;
    }
    return object;
};

The cool thing about javascript objects, is that they are all essentially maps of key-value properties. When we access a propery of an object, we can do so either through dot notation (e.g. c.Add(...)), or through index notation (e.g. c["Add"](...)). We take advantage of this when we create our mocked object. We enumerate over the members in the target object, and create stubs in the mocked object. Strings and objects become null, numbers become 0, functions get set to the empty function property, etc. The result is a copy of the object with stub members, ready to be configured.

Configuration is done using the mock class:

var Mock = function(graph) {
    this.Bindings = new Array();
    this.Object = MockUtility.CreateMockedObject(graph);
};
Mock.prototype = {
    Setup: function(name, member, args) {
        var object = this.Object;
        var bindings = this.Bindings;

        var binding = new MockBinding(name, member, args);
        bindings.push(binding);

        if (object[name] != undefined) {
            if (typeof(object[name]) == "function") {
                object[name] = function() {
                    for (var i = 0; i < bindings.length; i++) {
                        if (bindings[i].Name == name && bindings[i].Satisfies(arguments)) {
                            return bindings[i].Member.apply(object, arguments);
                        }
                    }
                }
            } else {
                object[name] = binding.Member;
            }
        }
    }
};

When we create an instance of the Mock class, we can use the Mock utility class to create the mocked object and assign it to the Object property of the mock instance. The prototype of the mock class defines the setup method. When we pass a function to the setup method, we create a binding and save any arguments being passed. The function of the object member is not the mocked function itself, but an intermediate function which matches the arguments being passed in to a saved binding. If any other type is passed in, the value is set in the mocked object directly.

Using the above, we can craft a (hopefully readable) mocked example that uses the mocked framework define here:

We define our interface again, and create a mocked instance:

var ICalculatorService = {
    Add: function() {}
};
var mock = new Mock(ICalculatorService);

We can then configure the mock. In our example , we'll make the result of the Add operation return 100 constantly:

mock.Setup("Add", function(operandA, operandB) {
    return 100;
}, [Is.AnyNumber, Is.AnyNumber]);

Next, we create our consumer class which uses an instance of the ICalculatorService:

var Calculator = function(service) {
    this.Service = service;
};
Calculator.prototype = {
    Add: function(operandA, operandB) {
        return this.Service.Add(operandA, operandB);
    }
};

Now, hopefully, when we call the Add operation, it should return 100 regardless, thanks to the mocked object.

var calc = new Calculator(mock.Object);
var result = calc.Add(1, 2);
// result should be 100,

So, hopefully this is a good start to developing a nice Mocking framework, probably to be utilised alongside a Javascript unit testing framework.

The script is attached, let me know what you think of the initial version.
Mock.zip

Using MEF with MVC Controllers

Matthew Abbott — Tue, 16 Mar 2010 14:54:57 +0000

I’ve recently been introduced to the Managed Extensibility Framework by a colleague at work, and have enjoyed picking it up so much it made me wonder how I could apply the simplicity of composition into my favourite web framework, ASP.NET MVC. There are a few obstacles to overcome initially, namely how instances are composed by default, and how the MVC system handles custom controllers. The idea behind this project, is to enable a Controller to be developed and deployed in it’s own assembly, with the ability to drop it into a project as an extension. Thus, as is the nature of MEF, this was down to exports and imports. MVC allows us to customise how controllers are created by implementing our own controller factory, so we can use this as well.

This initial problem with how MEF would work with MVC controllers, is that a controller is created when it is needed, not composed (and instantiated) straight away. In MEF preview 9, a great example project exists called DynamicInstantiation. In said project they’ve created a custom export provider and types, the PartCreator types. Using this method they can get the benefits of automatic composure with the added extra of dynamic instantiation. Basically, they can create instances of their dynamicly imported types, as and when they chose. This seemed pretty perfect for what I wanted to do with MVC.

I’ve taken that example project, fleshed out the code with comments and renamed the PartCreator types as PartFactory (that’s just my personal preference).

To get started with the project itself, I looked at the requirement for a controller. I’ve created a class library solely to house the custom controllers TestController. I’ve used [Export(typeof(IController))] to mark my controller for export, and also [ExportMetadata("ControllerName", "Test")] to mark my export with my desired metadata. This metadata will come into play later when we are instantiating an instance of our controller. I don’t need to define my own controller contract, as we can use the IController interface as our export definition.

namespace MEFLearning.MVC
{
    using System.ComponentModel.Composition;
    using System.Web.Mvc;

    /// 
    /// Defines an importable controller.
    /// 
    [Export(typeof(IController)), ExportMetadata("ControllerName", "Test")]
    public class TestController : Controller
    {
        #region Actions
        /// 
        /// The default action for the controller.
        /// 
        /// 
        /// As this is just an example, we'll redirect the user back to the homepage.
        /// 
        public ActionResult Index()
        {
            return RedirectToAction("Index", "Home");
        }
        #endregion
    }
}

Using the DynamicInstantiationExportProvider, we can create imports of PartFactory, instead of imports of IController. This is important, as when we compose whatever type is required, we don’t want it to automatically create instances of our controller. This only need happen when a request is made. To this end, I’ve created a new IControllerFactory, which allows us to create an instance of the controller only when it is required:

namespace MEFLearning.Web
{
    using System;
    using System.Collections.Generic;
    using System.ComponentModel.Composition;
    using System.Linq;
    using System.Web.Mvc;

    using MEFLearning.Web.ComponentModel;

    /// 
    /// Defines a controller factory that supports importing of controllers.
    /// 
    [Export]
    public class ImportControllerFactory : DefaultControllerFactory
    {
        #region Properties
        /// 
        /// Gets or sets the collection of controller part factories.
        /// 
        [ImportMany]
        public IEnumerable> PartFactories { get; set; }
        #endregion

        #region Methods
        /// 
        /// Creates an instance a controller with the specified controller name.
        /// 
        /// The context of the request.
        /// The name of the contorller requested.
        /// An instance a controller with the specified controller name.
        public override IController CreateController(System.Web.Routing.RequestContext requestContext, string controllerName)
        {
            IController controller = null;

            if (PartFactories != null) {
                // Determine if a factory is available for our controller.
                var factory = PartFactories
                    .Where(f => (f.Metadata != null
                                 && string.Equals(f.Metadata.ControllerName, controllerName,
                                                  StringComparison.InvariantCultureIgnoreCase)))
                    .FirstOrDefault();

                // Create an instance of the controller.
                if (factory != null)
                    controller = factory.CreatePart();
            }

            // If no imported controller could be found, use the default factory to create one where available.
            return controller ?? base.CreateController(requestContext, controllerName);
        }
        #endregion
    }
}

When the CreateController method is called by the MVC ControllerBuilder, we need to interrogate our PartFactories enumerable to find the available imported controller. One of the nice touches with how the imports are handled, is that the metadata we decorated on our TestController ([ExportMetadata("ControllerName", "Test")]) is projected as an instance of our interface, IControllerMetadata:

namespace MEFLearning.Web
{
    /// 
    /// Defines the interface for a controller metdata view.
    /// 
    public interface IControllerMetadata
    {
        #region Properties
        /// 
        /// Gets the controller name.
        /// 
        string ControllerName { get; }
        #endregion
    }
}

In vanilla-MVC, the controller is selected based on it’s name, minus the “Controller” suffix. Unfortunately, this wouldn’t work well with this solution, as the imported part type is IController, not TestController, and we can’t do a GetType() call on the instance, as we would have to create an instance ahead of time to do that. This is the design decision around using a metadata view. If the exported controller doesn’t have a ControllerName metadata attribute, it won’t successfully be instantiated. Small sacrifice, but I think it’s worth it.

I’ve used the DefaultControllerFactory type as a base, as it will allow us to create instances of controllers hosted in the main web project. For instance, we can keep the default HomeController and AccountController types in the website itself, the above implementation will still allow us to use them.

Routing
Controllers are pretty much useless without routes, and in light of the fact that MVC2 has the concept of AreaRegistration, I thought it would be a nice idea to have our routing handled by the MEF composition also. To this end, I’ve created a new contract, the IRouteRegistrar, which has two methods, RegisterIgnoreRoutes() and RegisterRoutes(). Handling these seperately allows multiple registrars to register their routes in a seperate fashion, this may be important due to the linear nature in which routes are selected. My contract is as follows:

namespace MEFLearning.MVC
{
    using System.Web.Routing;

    /// 
    /// Defines the required contract for implemting a route registrar.
    /// 
    public interface IRouteRegistrar
    {
        #region Methods
        /// 
        /// Registers any routes to be ignored.
        /// 
        /// The collection of routes to add to.
        void RegisterIgnoreRoutes(RouteCollection routes);

        /// 
        /// Registers any routes to be processed.
        /// 
        /// The collection of routes to add to.
        void RegisterRoutes(RouteCollection routes);
        #endregion
    }
}

We can take advantage of this, by having our default rules be implemented as a registrar:

namespace MEFLearning.Web
{
    using System.ComponentModel.Composition;
    using System.Web.Mvc;
    using System.Web.Routing;

    using MEFLearning.MVC;

    /// 
    /// Registers the default required routes.
    /// 
    [Export(typeof(IRouteRegistrar))]
    public class DefaultRouteRegistrar : IRouteRegistrar
    {
        #region Methods
        /// 
        /// Registers any routes to be ignored.
        /// 
        /// The collection of routes to add to.
        public void RegisterIgnoreRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
            routes.IgnoreRoute("{resource}.aspx/{*pathInfo}");
            routes.IgnoreRoute("{resource}.ico/{*pathInfo}");
        }

        /// 
        /// Registers any routes to be processed.
        /// 
        /// The collection of routes to add to.
        public void RegisterRoutes(RouteCollection routes)
        {
            routes.MapRoute("Default", "{controller}/{action}/{id}", new { controller = "Home", action = "Index", id = "" });
        }
        #endregion
    }
}

The DefaultRouteRegistrar is in the main website project, but having the ability to export our local types means it now fits nicely into our composition. For this example, I haven’t bothered creating any routes for the TestController, as the default route will handle it for now. I have created a TestRouteRegistrar stub which can be fleshed out when more complex routes are required.

Joing it all together
Originally I toyed with having a seperate host class that we could reference from our Global application class. In the end though, it’s perfectly viable to just use the MvcApplication type thats generated with our project as our composable type. Firstly, lets look at how we are composing our application:

#region Properties
/// 
/// Gets or sets the collection of route registrars.
/// 
[ImportMany]
public IEnumerable RouteRegistrars { get; set; }

/// 
/// Gets or sets the controller factory used for imported controllers.
/// 
[Import]
public ImportControllerFactory ControllerFactory { get; private set; }
#endregion

We decorate two properties here. We need our route registrars composed and available straight away, as with our custom controller factory. This all fits togther with our Application_Start method:

protected void Application_Start()
{
    // Create our part catalog and export provider.
    var catalog = new AggregateCatalog(
        new DirectoryCatalog(Server.MapPath("~/bin")),
        new DirectoryCatalog(Server.MapPath("~/bin/Imports")));
    var exportProvider = new DynamicInstantiationExportProvider();

    // Create the container used to compose parts.
    var container = new CompositionContainer(catalog, exportProvider);
    exportProvider.SourceProvider = container;

    // Compose our application.
    container.ComposeParts(this);

    // Set the controller builder to use our custom controller factory.
    ControllerBuilder.Current.SetControllerFactory(ControllerFactory);

    // Register any available routes.
    RegisterRoutes();
}

The nuts and bolts of it are a single AggregateCatalog which itself is composed of two DirectCatalog instances, one for the main application types (“~/bin”), and our for our imported types (“~/bin/Imports”). Not sure if it’s just me, but I was hoping the DirectoryCatalog would handle subdirectories (have I missed that)?

We create an instance of our DynamicInstantiationExportProvider which will allow the composition of PartFactory<> instances. Once thats all be composed, we can assign our ImportControllerFactory to the ControllerBuilder and register our routes:

/// 
/// Registers any required routes.
/// 
public void RegisterRoutes()
{
    RouteCollection routes = RouteTable.Routes;

    // Register our ignore routes.
    foreach (var registrar in RouteRegistrars)
        registrar.RegisterIgnoreRoutes(routes);

    // Register our processed routes.
    foreach (var registrar in RouteRegistrars)
        registrar.RegisterRoutes(routes);
}

Thats pretty much it, run the project and visit the /Test url, if all goes to plan it should redirect you back to the homepage. We could have done something a bit fancier, but I think this is a good starting point to a modular MVC project.

The project is attached for your viewing, let me know what you think.

MEF-MVCControllers.rar