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.
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.
So – following on the first part in my series on how I have been using Glass Mapper for Sitecore in the real world.
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 www.glass.lu.
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:
In xxx.Model, I would add my regular domain objects – so, ISitecoreItem, ITitleAndIntro : ISitecoreItem, IMetaData : ISitecoreItem
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
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.
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.