In Glass Mapper V4, we introduced an awesome feature for keeping your POCO objects isolated and allowing easier use of the fluent configuration API called Glass Mapper Configuration Maps. This post describes how you can auto-register all of the maps in a given assembly using your IoC container.
Recently I read this set of posts:
A post from Konstantin Cherkasov claiming Glass to be 2000 times slower than the Sitecore API
http://sitecorepro.blogspot.co.uk/2015/06/sitecore-and-glassmapper-how-much.html
A post from Kam showing Synthesis to be 3x slower than the Sitecore API
http://kamsar.net/index.php/2015/06/Synthesis-Object-Mapping-Performance/
and finally a post from Richard Seal showing Fortis performance:
http://www.sitecorenutsbolts.net/2015/06/11/Fortis-Object-Mapping-Performance/
In this post I look more into what makes this a fairly useless test in the real world and debunk the idea that Glass Mapper is actually 2000x slower than the Sitecore API.
This little featurette stemmed from a blog post on here looking at Getting a Sitecore Model from the cshtml. It’s something I think benefits us with Glass more than with regular Sitecore development.
Continue reading
Following on from my post on the new caching functionality in Glass Mapper V4, I thought I would do something that I have been really dying to try, which is to look at using Redis to cache the models generated out of Glass. This from an architectural standpoint for me is just plain amazing :D. In this post, I will show you how you can set up a redis based cache provider for Glass Mapper V4. This post will assume you know how to set up caching on your models (shown in my previous post).
** Note – this is a proof of concept, it has not yet been tested in production, all the regular no warranty disclaimers apply.
Something I had a look at quite a while back was the fluent configuration api in Glass. Unlike many developers, I am absolutely 100% fine with adding spaces to field names and don’t like using attribute based configuration in Glass. I talked about this in some detail a while ago in Introducing Glass Maps. I have since been through several iterations and finally settled on one that I like and therefore contributed to Glass itself. In essence, it is simply a neat way of bundling your fluent mapping into discrete units, which allows you to keep the mapping isolated from your POCO’s.
I understand this is not to every developers taste, but if you like to see clean .net objects, this my be the mapping configuration type for you.
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.
Following on in my series looking at the new features in Glass Mapper v4.
One of my favourite features of Glass V4 is the new Caching feature. This at at in its simplest form allows you to cache the object that Glass produces, much like we do in regular .net development for slower running processes. In this post I will describe some more about caching, how to set it up and what it does.
