Life Through a Lens – When to use Glass Mapper

This post is one that there is less of a right or wrong answer on, but it is my approach on how and when I look to use Glass Mapper in my solutions.

Even in the Official Glass Training it is made quite clear that Glass Mapper (or any other ORM / Wrapping framework) is not a silver bullet solution.

Generally speaking there are limitations on when you should / shouldn’t consider using an ORM in your codebase.

Controllers, Views

Any customer facing code should utilise Glass Mapper. Glass Mapper has distinct advantages on stock Sitecore in terms of rendering pipelines and also model caching. It also provides distinct advantages in terms of unit testability (especially with the use of GlassController or GlassUserControl).

Glass has Page Editor support covered and in many cases also allows the use of (faster) view renderings without the need for a controller in place

Pipelines, Commands

This HEAVILY depends on what the pipeline is doing, but as a general rule of thumb – I would not choose to use Glass Mapper directly inside pipelines or commands. I would however sometimes support sending something like arg.Item.ID.ToGuid() down to service layer code (which is heavily unit tested) and use Glass within it, but I would consider heavily the impact of performance (see below).

Be aware that all ORM / wrapping frameworks carry a weight over and above the default Sitecore, so there is another heavy argument against using it in code that is repeated a lot – e.g. rendering pipelines, item resolution pipelines.

Indexing operations

Generally speaking, the logic behind most modifications you would make to the indexing process (computed fields etc) is not sufficient to really warrant plugging and unplugging an ORM, so if you can get away without it and still have it testable, then there is no need, if not then it would be worth considering.

SPEAK / Sheer UI

This one is somewhat more woolly. Glass is geared up to use the current context as the basis for operating. You can of course (using ISitecoreService) specify a different database – something like the ContentDatabase for example. In many cases in the back end of Sitecore, this can result in it still utilising the wrong database. If you can overcome these issues, then I see no reason not to use Glass Mapper.


Glass Mapper or any ORM / wrapping frameworks do provide a great level of testability & maintainability for your Sitecore solutions, this will always have a cost. Consider whether the testability / maintainability outweighs in each use case.


Leave a Reply

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

You are commenting using your 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