Data Layer and Performance

Before I started working with Sitecore exclusively so many years ago, my day to day work involved a lot more database interaction. Of course a good chunk of that time was with PHP and MySQL but the concept was the same. Write database calls that got you what you wanted while limiting the trips back to the server.

With Sitecore we lose that close relationship with our databases. But don’t get me wrong, I enjoy the fact that the Sitecore framework does a lot of that heavy and sometimes tedious lifting for us. But with that disconnect it is also easy to forget that every new item creation is a call to database.

Furthermore if you are writing code for a Sitecore site I hope you are using some sort of a data layer. Something that centralizes your item definitions for easy updates down the road. But in the process of doing this, you might be disconnecting what you or another programmer might use your data class down the road. Remember that calling a Sitecore item is equivalent to a trip to the database.

Take for example the BlogPost data class from XBlog. In this class we are calling all fields that are present on the blog page item. So title, summary, description, etc.. But the ones that we found can get you in trouble real fast are our multi-list fields. Here is our category call:

[SitecoreItemField(BlogPostCategoryFieldId)]
        public virtual List Categories { get; set; }

With this call, we have now taken the use of this class from calling one item to calling that item and whatever items that live on this list. Not such a big deal if we are just calling up a single blog post. But what if we are displaying a list of blog posts? You’re five or six item calls could all of sudden become hundreds or even thousands. And in the case of our example we are only looking for basic information like title and summary.

Here are some suggested approaches to this:

If you are using a search engine to build your list, consider just using the search item. See if the fields present there can get you what you need. You can always use a data layer class for this just like you would for a Sitecore item.
Instead of transforming multi-list fields into a List type of another data class, consider just a string. This would give the raw value of the field which is simply a list of guids. In some cases this is good enough.
Finally create an alternative class. Something that is a simple form of what you need. If you structure your Sitecore items properly you could also create base classes that are void of lists, and have those lists on another class that inherits the base. Leaving you open to use that base class when you need much simpler / faster version of the item.

I hope this article helps the next time you are scratching your head wondering why your Sitecore page is taking a few seconds to load!