Hjalmar Moa
Jan 27, 2010
(0 votes)

Some thoughts on using the Repository design pattern

There is plenty of talk about MVC vs. Web Forms going on. One thing that MVC pushes for is small controller classes and a rich domain model. A rich domain model is equally useful in Web Forms but somehow seldom implemented.

Using a tiered design, logic is to be placed in the business layer and the presentation should be in the user interface. A lot of times business logic is nested with presentation logic in a big non-reusable pile.

One way to move some logic into the business layer is to create a “Repository” class for some types of data.

As an example, a CalendarEventRepository could be created that get the events which are displayed in the calendar on a website.

The following example shows you how to fetch pages from a set location. The page types are specified with Page Type Builder so we can filter them by type in an easy way.

   1:  public class CalendarEventRepository : RepositoryBase<CalendarItemPageType>
   2:      {
   3:          /// <summary>
   4:          /// Get the calendar events from the specified year
   5:          /// </summary>
   6:          /// <param name="language">language branch</param>
   7:          /// <returns>all events</returns>
   8:          public static ICalendarEvent[] GetCalendarEvents(string language)
   9:          {
  10:              CalendarItemPageType[] items = GetPagesFrom(SettingsPageType.Instance.CalendarPage, language);
  11:              if (items == null)
  12:              {
  13:                  log4net.LogManager.GetLogger("CalendarEventRepository")
  14:                      .Debug("Settings.CalendarPageLink is not set");
  16:                  return new ICalendarEvent[0];
  17:              }
  18:              if (items.Length == 0)
  19:              {
  20:                  log4net.LogManager.GetLogger("CalendarEventRepository")
  21:                      .Debug("No pages of type 'CalendarItemPageType' below page " + SettingsPageType.Instance.CalendarPage.ID);
  23:                  return new ICalendarEvent[0];
  24:              }
  26:              items = items
  27:                  .OrderBy(page => page.PageDate)
  28:                  .ToArray();
  30:              return items;
  31:          }

The base class has a function that get the pages of choice

   1:      public abstract class RepositoryBase<T> where T: TypedPageData
   2:      {
   3:          protected static T[] GetPagesFrom(PageReference pageLink, string language)
   4:          {
   5:              if (PageReference.IsNullOrEmpty(pageLink)) return null;
   6:              PageDataCollection children = DataFactory.Instance.GetChildren(pageLink, new LanguageSelector(language));
   7:              EPiServer.Filters.FilterForVisitor.Filter(children);
   9:              T[] items = children
  10:                  .Where(page => page is T)
  11:                  .Select(page => page as T)
  12:                  .ToArray();
  14:              return items;
  15:          }


Our page type implements an interface so we can return a loosely coupled reference:

   1:      public class CalendarItemPageType : DatePageType, ICalendarEvent

The advantages

“Separation of concerns” has been a big topic lately. The page shouldn’t have to know how the calendar is implemented, it should trust the repository to send the data it needs. The repository should just serve the data and not be bothered who uses it.

The repository returns an interface for the same reason. The class using the repository doesn’t need to know that the repository is really just returning a page.

Having returned an interface gives us the freedom to change the implementation of the repository without changing anything else on the site. The events could equally well be classes hosted in the Dynamic Data Store, or returned from a RSS feed.

Is it worth the bother?

I have heard some times that it is overkill to create an entirely new class just to get some child pages.

This might seem a good enough reason to start with, but code tends to grow overtime. Soon the excuse is that it is too many places to change instead.

The second excuse is that it is too hard to understand code that uses interfaces. I don’t have a good comment on this….

What’s your opinion?

Jan 27, 2010


Sep 21, 2010 10:33 AM

Good one, Hjalmar!

I believe I have to get knee-deep with your solution in a project to see the benefits. I do, however, love separation of logic in your approach.

Very elegant code. :) Major kudos!

Hope everything is well up with you and the team in the H&H fortress!
/ Daniel Berg

Please login to comment.
Latest blogs
How to Write an xUnit Test to Verify Unique Content Type Guids in Content Management

When developing an Optimizely CMS solution, it is important to ensure that each content type has a unique GUID. If two or more content types share...

Minesh Shah (Netcel) | Mar 27, 2023

Extend TinyMCE in Optimizely CMS 12

Since technologies are upgraded to newer versions the ways to extend or override the out-of-the-box functionality are also changed a little bit so...

Ravindra S. Rathore | Mar 27, 2023 | Syndicated blog

Telemetry correlation for Scheduled Jobs in Optimizely

I previously demonstrated how to correlate telemetry to Azure Application Insights within a Hangfire job. But how about those jobs that are built a...

Stefan Holm Olsen | Mar 23, 2023 | Syndicated blog

Fixing Optimizely Content Syncing/Caching Issues on the DXP pre CMS.Core 12.13.0

Hi all, With our recent deployments to the DXP for .NET 6 projects (one a new build and one an upgrade) our clients had raised issues where there...

Scott Reed | Mar 23, 2023

Handle hostnames, schedule jobs and role access when synchronizing content

The Environment Synchronizer module helps you to set your environment into a known state after synchronizing databases between environments. In thi...

Ove Lartelius | Mar 23, 2023 | Syndicated blog

4 tips and tricks for Hangfire on Optimizely CMS

Here are four useful tricks I always apply to any site where I use Hangfire (code included).

Stefan Holm Olsen | Mar 21, 2023 | Syndicated blog