EPiServer  /  CMS May 30, 2010

An opinionated abstraction of DataFactory?

Given that you use EPiServer CMS and Page Type Builder and are interested in testing (or rather writing maintainable and flexible applications that abide by well tested design principles) you have probably found yourself needing an abstraction/facade/wrapper for EPiServer’s DataFactory that doesn’t just abstract a few common methods, such as IPageSource, or every single method in DataFactory such as EPiAbstractions IDataFactoryFacade but instead aid you in your daily work by abstracting, and implementing, commonly used operations utilizing the type safety and polymorphism that using Page Type Builder provides.

What I’m proposing is creating an interface and standard implementation of it that:

  • Has a GetPage() method.
  • Has a GetPage<T>() that returns an instance of the specified page that is of type T, given that the page is of a page type that matches or inherits from T. Otherwise it returns null.
  • Has a GetChildren() that works just as DataFactory’s.
  • Has a GetChildren<T>() that returns children of type T.
  • Has a GetDefaultPageData<T>(). Figuring out the Id of a page type when creating a page programmatically is at best boring…
  • Has a GetDescendents() method that works just as DataFactory’s.

Optionally it could also:

  • Have a GetAll<T>() that returns all pages of the exact type T, implemented using FindPagesWithCriteria.
  • Have a GetDescendents<T>() implemented using recursive calls to GetChildren.
  • Have a GetChildrenVisibleForVisitor<T>() that returns children after first filtering them using FilterForVisitor’s Filter method. Optionally it could accept the user as a parameter and use a different way to filter than the FilterForVisitor class.
  • Have a GetChildrenVisibleInMenus<T>() that works like the above but also filters out pages not visible in menus.


If I go through with this there are a few questions that needs answering:

  1. What should the interface and class be called? IPageRepository and PageRepository?
  2. Where should it have it’s home? It’s dependent on Page Type Builder but doesn’t belong it Page Type Builder. I’m thinking about adding a new project to EPiAbstractions called EPiAbstractions.Opinionated because that’s just what this is, an opinionated abstraction.
  3. What methods should it include? Have I missed any in the above listings?
  4. Are the non-typed methods (GetPage, GetChildren) even necessary? You can just as well use GetPage<PageData> as GetPage().
  5. Should methods that returns collections return IEnumerable<T> or List<T> or something else? Why?
  6. Would you use it or would you (continue) creating your own wrappers for DataFactory?

What do you think? Let me know with a comment!

PS. For updates about new posts, sites I find useful and the occasional rant you can follow me on Twitter. You are also most welcome to subscribe to the RSS-feed.

Joel Abrahamsson

Joel Abrahamsson

I'm a passionate web developer and systems architect living in Stockholm, Sweden. I work as CTO for a large media site and enjoy developing with all technologies, especially .NET, Node.js, and ElasticSearch. Read more


comments powered by Disqus

My book

Want a structured way to learn EPiServer 7 development? Check out my book on Leanpub!

More about EPiServer CMS