In part one of this two-part series, I took a brief look at the fundamental differences between object mapping with the Sitecore API, Glass.Mapper, and Synthesis.
For part two, I'm briefly looking into the setup effort, learning curve, and day-to-day usage considerations for each ORM that will help you choose the best tool for your project. There is no universally "correct" tool to use with Sitecore, but this list is intended to help you understand the pros/cons of each tool.
Sitecore API
Setup
Zero: that's the number of minutes you'll spend getting started with the Sitecore API (granted you reference the correct Sitecore DLLs or NuGet packages in your projects). Your first line of code in your first controller could be this:
Item console = Sitecore.Context.Database.GetItem("/sitecore/content/consoles/switch");
... and now you have the console object with all the fields and content that authors have created. Obviously the above example is over-simplified and ignores a lot of best practices, but this is functional Sitecore API code.
You will realistically want to wrap the Sitecore API in helper methods or repositories that help validate data coming from Sitecore, cast data types, and maybe even map to strongly-typed models.
Learning Curve
Because most developer tools utilize the Sitecore API, it's critical that all developers have a fundamental understanding of the native API. Learning how the Sitecore API works is critical to understanding the benefits of other tools and libraries (like Glass and Synthesis).
Luckily, the Sitecore API is well-documented and well-understood by the majority of the Sitecore community, so resources and references are plentiful. Like any API, striking a balance between consuming documentation and writing real code is the best way to learn.
Day to Day Usage
While it is the quickest way to get started with Sitecore content, the native API presents long-term architecture challenges if not utilized properly.
It's important that developers understand that the Sitecore API requires lots of type-checking and the user of helper classes/methods before utilizing content, and this may create a steeper learning curve than initially implied. In other words, developers may end up writing a lot more boilerplate than expected:
Item item = Sitecore.Context.Database.GetItem("/sitecore/content/consoles/switch");
if (item != null)
{
ConsoleModel model = new ConsoleModel();
model.Name = item.Fields["Console Name"] ?? string.Empty;
if (item.Fields["Console Picture"] != null)
{
ImageField imgField = (ImageField)item.Fields["Console Picture"];
MediaItem imgItem = new MediaItem(imgField.MediaItem);
model.ConsolePictureURL = MediaManager.GetMediaUrl(imgItem);
}
return View(model);
}
That's a lot of code just to retrieve two fields and populate a model (and I'm still missing a few null- and type-checks).
I would suggest that a developer or architect create helper methods and classes to wrap and hide some of this complexity, while faciliting a standard interface for accessing Sitecore items via the API, ultimately encapsulating the above code behind a method like this:
ConsoleModel item = ModelService.GetConsoleModel("/sitecore/content/consoles/switch");
When things go wrong for developers, the Sitecore API is relatively easy to debug. The API is usually as close to the data layer (ie, content databases) as you code can be, so common debugging and content-to-code comparison techniques usually suffice to solve problems.
Glass.Mapper
Setup
Getting started with Glass.Mapper means parsing out which NuGet packages you need for your particular version of Sitecore. See this compatibility chart to get started.
Once you get the NuGet package installed, there's some (optional) configuration tweaks that can be made, but for the most part, you can start creating strongly-typed models, decorate them with Glass attributes, and begin loading and mapping content from Sitecore items.
Learning Curve
Glass is one of the most popular ORM tools for Sitecore, and is well documented, studied, and understood by the developer community. Learning how to use Glass can be tricky, however.
Earlier versions of Glass (prior to v5) have extensive documentation, blog articles, videos, and support articles published. The vast majority of that knowledge applies to the latest version too, so Glass isn't hard to learn.
The latest version of Glass - v5 - replaces extensive documentation with paid training. Minimal documentation still exists, however, and when combined with v4 documentation, still makes Glass relatively accessible to developers.
Most developers should be able to understand Glass' one-line mapping methods and context classes within a day.
Day to Day Usage
Once up and running, developers have two common tasks to do when using Glass.Mapper: 1) create and decorate POCO models and 2) get content from Sitecore using Glass methods. A typical MVC developer will need to create strongly-typed models that represent Sitecore content, then use attributes to tell Glass how it should map data types from content to the models. For example:
public class ConsoleModel
{
[SitecoreId] // Tells Glass to assign the item's ID to this
public Guid Id { get; set; }
[SitecoreField]
public string Name { get; set; }
[SitecoreField]
public Glass.Mapper.Sc.Fields.Image ConsolePictureURL { get; set; }
}
That model can then be mapped with minimal code:
var mvcContext = new MvcContext();
ConsoleModel model = mvcContext.GetItem<ConsoleModel>("/sitecore/content/consoles/switch");
return View(model);
When things go wrong, Glass has multiple possible points of failure that make debugging a moderately difficult exercise. POCO models may be configured incorrectly, configuration may be wrong, context objects may not instantiate properly, etc.
Synthesis
Setup
As suggested by the official installation instructions, setting up Synthesis is a two step process: 1) install the latest NuGet package and 2) optionally tweak settings in the Synthesis.config file. A lead developer or architect is usually in the best position to run through this (moderately easy) configuration process. Once configured properly to generate models from Sitecore templates.
When (optionally) combined with Leprechaun for Rainbow-based model generation, setup and configuration becomes a moderately difficult task and requires that multiple configuration files are set up properly.
Learning Curve
The GitHub page for Synthesis provides enough direction for most developers to get started with common scenarios. Common day-to-day tasks and content-based components can be built with minimal learning. More advanced topics can be found in the in the wiki. Tweaking the behavior of model generation or integrating a Unicorn/Leprechaun build process will quickly send developers down the Synthesis rabbit hole, however.
Day to Day Usage
Synthesis is all about front loading its setup process. Once configured properly, developers only have to concern themselves with loading a Sitecore item and mapping to the generated models using Synthesis extension methods:
Item item = Sitecore.Context.Database.GetItem("/sitecore/content/consoles/switch");
ConsoleModel model = item?.As<IConsoleModel>();
return View(model);
When things go wrong, Synthesis issues are sometimes difficult to debug. The most common problems involve errors with model generation, which are almost always caused by configuration errors.
The Bottom Line
Of the three tools discussed, there is no single right one for your project. I ultimately think that developer experience with each tool plays a major role in deciding which to use. If the playing field were leveled, however, my final takeaway reads like this:
Sitecore API
- Pro: zero setup time
- Pro: great for simple, content-driven components
- Con: requires lots of extra abstraction for quality architecture
Glass
- Pro: well-supported and well-understood by dev community
- Pro: easy to start and quickly learn
- Con: verbose at times (need to create POCO models)
Synthesis
- Pro: easy to get started
- Pro: all models are generated
- Con: requires more effort to support and debug