I’ve been told IContentRepository.GetItems is heaps better. And when I asked  people why? They told me it is built DB load. Just want to clarify this. You pass a list of ContentReference (IEnumerable<ContentReference>) and it loads all IContent for each item. This seems to build DB load but when you take a look into code it does build load from MEMORY CACHE otherwise, it does load individually:

class EPiServer.Core.ContentProvider:

    protected virtual IEnumerable<IContent> LoadContents(IList<ContentReference> contentReferences, ILanguageSelector selector)
      IList<IContent> contentList = (IList<IContent>) new List<IContent>();
      foreach (ContentReference contentReference in (IEnumerable<ContentReference>) contentReferences)
        IContent content = this.Load(contentReference, selector);
        if (content != null)
      return (IEnumerable<IContent>) contentList;

So please consider this as  performance consideration.

2 thoughts on “IContentRepository.GetItems – how it works under hood!

  1. The code shown is form the ContentProvider base class. The reason it is implemeted like this is so that a content provider implementation deriving from it does not have to implement batch loading. But if you want to implement batch loading, you just override this method, which is what both the CMS DefaultContentProvider and the Commerce CatalogContentProvider do. So a call to GetItems which ends up in these content providers will in fact mean that content is loaded form DB in batches (it will check cache for each requested item first, and then load the missing items in batch).

    1. Very good point mate. I may try that and just to emphasize some of colleague assume this is batch out of the box which is not! We had an issue with performance and I dig down and found this wrong assumption. But again thanks for your help again I will try to make a sample. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *