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:
- What should the interface and class be called? IPageRepository and PageRepository?
- 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.
- What methods should it include? Have I missed any in the above listings?
- Are the non-typed methods (GetPage, GetChildren) even necessary? You can just as well use GetPage<PageData> as GetPage().
- Should methods that returns collections return IEnumerable<T> or List<T> or something else? Why?
- Would you use it or would you (continue) creating your own wrappers for DataFactory?
What do you think? Let me know with a comment!
- EPiAbstractions.Opinionated – A wrapper for EPiServer CMS and Page Type Builder
- Page Type Builder 0.8 released – Finally!
- Dependency Injection with Page Type Builder 1.2
- A toolset for building testable and flexible EPiServer CMS sites
- A plea to the EPiServer backend team
- Automatically organize EPiServer pages
- How EPiServer CMS caches PageData objects
- PageData objects not returned as typed when using Page Type Builder and FindPagesWithCriteria