Glass Mapper V4 – Windsor Removal

Glass V4 is nearly upon us, and I am pretty damn excited! This series is looking at the latest features and improvements they have to offer.

In this blog post I am going to look at the changes to the registration API, particularly the removal of the dependency on Castle Windsor and how they have changed the face of Glass Mapper on the Sitecore platform.

History

Firstly I guess – understand that Glass has never been ‘dependent’ on Castle Windsor or any other container for that matter. To date – it has been the default implementation. I fully understand why it has met with reluctance – especially given the number of containers Sitecore ships with *cough* – sort it out guys – *cough*. There have however been plenty of alternative ways to implement Glass mapper using the container of your choice – or indeed no container at all.

So – what have they done?

I know from many conversations with developers, reading blogs, stack overflow questions, twitter posts and all sorts of other interactions, that Glass’ ‘dependency’ on Castle Windsor has divided opinion or at least raised questions on ‘how can I use StructureMap / SimpleInjector / Autofac?’. For these reasons, Glass decided to look at more agnosticism of the registration mechanisms and allowing developers the ability to change the components that are registered with Glass. To this end, Glass asked me to take a look – which I duly did.

The first iteration was indeed just that – a container agnostic ‘Conforming Container’ implementation, and this was present in early builds of Glass V4.

On further discussion however, it was identified that a potential better solution would be to drop the container altogether in favour or ‘something else’.

That ‘something else’ has come in the shape of a completely renewed registration API which not only allows easier addition but also allows the use of IoC containers should you choose. For legacy support, Glass will provide a Windsor package, but this is no longer the preferred method.

Using an IoC container

As explained above, the ability to choose to use an IoC container was key to the decision making process, and to this end – here is an example of how you could achieve just that.

I created a simple ContainerFactory class that does nothing but returns the result of an IEnumerable from it’s injected constructor parameters.

    public class ContainerFactory<T> : IConfigFactory<T>
    {
        private readonly IEnumerable<T> maps;

        public ContainerFactory(IEnumerable<T> maps)
        {
            this.maps = maps;
        }

        public void Insert(int index, Func<T> add)
        {
            throw new NotSupportedException("You cannot add to container registration based factories");
        }

        public void Add(Func<T> add)
        {
            throw new NotSupportedException("You cannot add to container registration based factories");
        }

        public IEnumerable<T> GetItems()
        {
            return maps;
        }
    }

In my container registration, I then registered the component IConfigFactory with the service ContainerFactory. Using this, I can simply replace the ConfigurationMapFactory property of the dependency resolver during its creation with my own (in the generated GlassMapperScCustom). It really is that simple.

        public static IDependencyResolver CreateResolver(){
            var config = new Glass.Mapper.Sc.Config();

            var dependencyResolver = new DependencyResolver(config);
            
            // Replace the default configuration map factory with one using my container manager.
            var configManager = new ContainerManager();
            dependencyResolver.ConfigurationMapFactory = configManager.Resolve<IConfigFactory<IGlassMap>>();

            return dependencyResolver;
        }

In a similar manner you can replace any of the containers / registration functions at will. This will be particularly handy for Caching & Configuration Maps

Insertion & Addition

In addition to changing how the api gets its registrations by replacing the factories / func’s, Glass also wanted to focus on allowing the addition of registrations without replacing the whole implementation. This is PARTICULARLY useful for adding custom data mappers.

Any of the default factories can be added to by simple doing something like the following.

dependencyResolver.DataMapperFactory.Insert(12, () => new MyDataMapper());

You could therefore equally do this out of an IoC container or whatever else you choose.

Advertisements

2 thoughts on “Glass Mapper V4 – Windsor Removal

  1. Hi,
    I have used the same code. but for me, I am getting error, type or namespace not found for “ContainerManager” class. Then, I have added a class and property name container. Still, I am getting error in GetAllInstances().
    Please help

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s