Life Through A Lens – Using your own IoC container with Glass Mapper

This should be a nice quick post, but when I look back, it’s something I have done on every project I have used Glass Mapper on.

Glass’ out of the box Castle Windsor implementation tends to create it’s own IWindsorContainer during Sitecore’s initialise pipeline (formerly done using WebActivator). This is great if you want to get up and running quickly, but in my case – especially with the new Delegate mapping function available, I often find that I would rather have a more global container than this, since – for example, some of the delegate mapping does use dependencies from my codebase.

In this post I will quickly describe how to use an external Castle Windsor container with Glass Mapper. If you want to find out more on using other IoC containers including Autofac, StructureMap or Unity as the container for Glass, please take a look at Glass Mapper On Agnostic IoC

Continue reading

Life Through a Lens – Glass Tip – Casting Items to Objects in Glass Mapper

This actually should be a fairly quick post, but one that I have seen a few times over now. It is simply a quick answer to the following question – ‘how can I get a POCO (object) given the Sitecore item?’. Before you question too much, I will also explain why the answer is (mostly) not GlassCast(this Item item). This question crops up reasonably regularly, especially given the number of pipelines / commands where we are presented with the item as an argument. There are actually a few considerations when looking at this question and some better and worse ways of achieving this. This post covers many of the common mistakes I have seen when using Glass Mapper in my implementations.

Continue reading

Glass Mapper – Agnostic IoC Source

Just a very quick post

This evening I released the source for Glass Mapper running on Agnostic IoC in a more useable format.

You can find it here

This is a great opportunity to get to grips with how Agnostic IoC can be used (especially with Sitecore) to give your modules the flexibility you desire them to have.

Please do feedback on your experience.


Life Through A Lens – Unit Testing your .net code using Glass Mapper

So now I have gotten my first couple of Sitecore User Group presentations out of the way – I thought I would actually continue on my journey of showing how I use Glass Mapper on the Sitecore platform in real world application.

As you will see from other posts I write – I am very much a TDD advocate. I find it helps focus my mind much better than simply writing code ad-hoc. Also – I hate testing, but love coding – so what better way to get my testing done than coding.

In choosing an ORM, I believe this should be one of your primary criteria since you are going to take some sort of performance hit with it being in the way and for me, trying to justify as just being ‘prettier’ code doesn’t really cut it when you are presenting it to a wider team.

With this in mind, I thought I would kinda tie these two together and look at how I use Glass to perform unit testing on *MY* code.

Continue reading

Life Through A Lens – Component Parts

So – following on the first part in my series on how I have been using Glass Mapper for Sitecore in the real world.

Glass Mapper
Just a couple of quick notes on Glass Mapper, the Glass Mapper developers have done a great job of writing tutorials on most aspects of Glass, and I expect with recent developments on the project, this will only get better, so please check them out at

Firstly – Whilst Glass supports using classes for mapping, I almost always use interfaces to represent my model objects, this is due to their multiple inheritance structure and it allowing better representation of the templates on which they are to be based.

Secondly – I almost always use the fluent configuration API – however… I almost always choose to configure this using my Glass Mapper Maps project (described below)

Finally – I like to turn the Automapping feature off for the most part, this is probably because I am a control freak :D.

Glass Mapper Maps
I have been in many discussions with the developers at Glass and I am hoping that this is one of the improvements that they will consider rolling into the product as a whole. Whether this is the case or not – here is what they are and how I use them.

Glass Mapper Maps are a neat solution to isolating the domain objects for use with Glass Mapper. Generally in practice, I start off by creating 2 projects in Visual Studio, these are:

  • xxx.Model
  • xxx.Model.Mapping

In xxx.Model, I would add my regular domain objects – so, ISitecoreItem, ITitleAndIntro : ISitecoreItem, IMetaData : ISitecoreItem

Agnostic IoC
Agnostic IoC is an abstraction layer to allow modules to utilise an unknown final IoC framework, this means that I can perform my registrations and resolves against Agnostic IoC and it in turn performs them against the container of choice. It does this by means of Nuget Packages.

With Glass Mapper, this means that I can use Glass with multiple clients complying with their restrictions of IoC container – be it Autofac, Unity, NInject, StructureMap or pretty much anything else. It also has the upshot of including it in the project, so any module development I choose can also be portable.

So now when I install Glass I need at least the following Nuget Packages

  • Glass.Mapper
  • Glass.Mapper.Sc
  • Agnostic.IoC

Wherever you actually want to perform the initialisation for Glass you also need to include the ‘Translator’ package, so for example – Agnostic.IoC.Autofac. You do not need this in any projects that are not performing the initialisation.

For a more in depth description, please visit Agnostic IoC


In the next post I will be looking at getting Glass Mapper up and running in your solution fully.

May I also draw your attention to the fact that the Glass Development team will shortly be offering training and consultancy on their products which I would highly recommend if you get the opportunity.

Life Through a Lens – My Glass Mapper With Sitecore

So you are here because you are either using Glass Mapper or want to know more on how to, particularly on the Sitecore platform. This series will be attempting to relate the use of Glass Mapper to real-world scenario’s which I have encountered, problems I have solved, approaches and / or idea’s on how you could use Glass Mapper in your own Sitecore implementations.

This is the first post in a series that I intend to run looking specifically at my experience of Glass Mapper, starting with what it is, how I use it and some common issues and hopefully a bit on TDD with Glass Mapper on the Sitecore Platform.

I will focus more on the MVC implementation during the course of the series, but Glass Mapper is equally potent and simple to implement when using purely Webforms (though I feel it’s testing benefits are more limited).

I would not knock other ORMs in this space and I hope not to compare Glass to it’s alternatives during the course of this series.

Continue reading

Glass Mapper – Introducing Glass Maps

This is due to be released in an upcoming module (along with the delegate mapper described here), however – here is a sneak preview of what I have been working on for Glass Mapper.

I think Glass Mapper is a fantastic and versatile ORM for Sitecore, however one of my slight bugbears with Glass Mapper as it stands is this. I want to build my POCOs as isolated as they can be. Glass Mapper has provided a fluent API which is grand, but the implementation by default leaves it a little short in my humble opinion. Out of the box, it’s a bunch of configurations that you add to the GlassScCustom (or in your own) class. In addition to this, if you want to support inheritance – say IExtendedSitecoreItem : ISitecoreItem you have to define all of the mapping for ISitecoreItem on IExtendedSitecoreItem as well. There are ways in Glass to sort this – using imports and the like, but you can end up with the framework excepting if you import the same thing twice. For me, I wanted an interface similar to that of fluent nHibernate, using a mapping generic to provide the mappings in an isolation from the original POCOs so I have created just such a thing:

Continue reading

Agnostic IoC Pt 1- Building Glass Mapper for Autofac, StructureMap, Windsor By Changing 1 Nuget Package

As a few of might already know, we started a project a short while back to overcome the difficulties developers face when building reusable modules for systems. This project was centered on the need to continually write our inverted dependency calls manually to avoid ties to an IoC container such as Autofac / Windsor. Recently a client of mine and also a friend have independently approached me about this subject. The former wants to commission me and Simon from the team here, to help them out on a build for a client of theirs, this client has asked that we use Autofac as the dependency container and Glass Mapper as the ORM. The second wants to be able to use Glass Mapper with their current implementation, they however use structure map.

It would have been a reasonable enough task to duplicate and modify the Windsor implementation from github twice to allow this to happen, but I fancied a challenge and thought this would be a good test of the Agnostic IoC extensions that I have written and talked about Here. After all, it is the near perfect use case for such an implementation – 1 framework with a choice of end IoC containers depending on the client.

What is Agnostic IoC?
Agnostic IoC is a set of extensions that aims to abstract the IoC container away from the final consuming implementation, you write your code against Agnostic IoC and it adapts the calls to the real IoC. You can initialise it from self discovery on adapters or simply push in your own already built container. It in many cases will not replace your own IoC implementation, it’s primary focus is to allow you to ship your reusable modules so others can enjoy them without tying them to particular versions of IoC containers. If the IoC container of your choice isn’t supported, it is quick and easy to write an additional one simply by inheriting from the abstract ContainerManager class. When consuming the application, you simply need to install the nuget package that matches your chosen IoC. If you need to get at any of the original functionality – the ContainerAdapter is a generic in its own right, you can simply cast something like myContainerManager.Container as IWindsorContainer to get back to the original container (that said – you can push your own in so not sure how much use it will be 😉 )
Continue reading

Controlling glass fields from your own code.

I make no secret of Glass Mapper being my current ORM of choice on the Sitecore platform but recently (not for the first time) I came across the need to control the mapping process in a crazier manner than Glass allows out of the box.

Glass provides a good set of structures to allow you to extend its behaviour when it comes to the mapping process and I utilised this to hook in and provide a ‘Delegate’ fluent mapping. This mapping allows you to delegate the behaviour of the mapping process back to code you control using a simple mappingContext.Delegate(x => x.MyField).GetValue(y => GetMeTheField(y.Item)). This is similar to the mappingContext.Field() or mappingContext.SitecoreInfo() methods that Glass Mapper provides out of the box.
Continue reading