Glass.Mapper is a great object-relational mapping (ORM) tool built on .NET for the Umbraco and Sitecore platforms. As a Sitecore Platinum Implementation Partner, Perficient and its developers use the best tools available, and Glass.Mapper is right up there in our preferred Sitecore tool belt.
As a Sitecore developer interested in using Glass.Mapper, you should consider one important architectural decision that can really impact ease of development and long-term maintenance of your project: should you write C# interfaces or concrete classes to represent Sitecore data?
The Basics: Templates to Objects
At its most basic, Glass.Mapper maps a Sitecore template to a strongly-typed C# object – very POCO friendly. Template fields are exposed as read/write properties, and distinct classes allow for easy testing. This allows you to quickly mirror your templates in code and have easy access to your content fields.
Best of all, Sitecore’s multiple template inheritance can be easily represented via Glass.Mapper, but here’s the catch: C# does not allow multiple inheritance for concrete classes, but does support the concept via interfaces. With this in mind, is there a best practice for designing classes/interfaces with Glass.Mapper? Let’s take a quick look at both options.
Concrete Classes
While concrete classes lack multiple inheritance, they do support base classes, which can be useful for modelling Sitecore’s basic item fields (ID, ItemName, DisplayName, Path, etc.) on a base class, then extending that with a template definition as necessary. This also lets you add methods directly on the classes, which helps consolidate business logic and simplify discovery of functionality.
Because inheritance options are limited, concrete classes work best for content with simple structures and limited repeatability – in other words, a site with a small number of Sitecore templates or those with overall simple structures.
Interfaces
Because interfaces can be inherited multiple times, Sitecore items with multiple templates are a natural fit.
In my experience, this works best when you keep data modelling simple: use interfaces to model Sitecore templates as if you were building simple POCOs. Start by creating an interface based on each of your templates (including necessary inheritance from other templates), then let Glass.Mapper do the heavy lifting of mapping across all said interfaces. Don’t try to implement concrete classes and extend logic or add custom fields/properties. Just read/write data from Sitecore and use helper classes or extension methods to add functionality around your models.
Previous versions used the Castle Windsor IOC library to generate proxy objects, but the new-for-2015 Version 4 uses the factory pattern to accomplish the same thing.
For additional information on interface implementation with Glass.Mapper, refer to this documentation.
Choose Wisely
Glass.Mapper works best when your data modelling is kept simple: use C# interfaces to model Sitecore templates. Only consider concrete classes for simple data structures and small websites. If you want to mix-and-match, you can define interfaces and implement concrete classes farther down the inheritance tree, but remember that you will have to implement methods and members for all inherited interfaces – which negates the simplicity of Glass.Mapper quite a bit.
