When Helix was released, the Sitecore community was very excited. For those of you who may be new to Sitecore, Helix is a set of overall design principles and conventions authored by Sitecore itself. Many partners had been following some of these conventions already, but now everybody had a common model to follow.

Related: How to add help text to Sitecore’s page editor.

The thing that caught my eye the most was the architecture principle of layers. As developers, many of us are already familiar with the idea of layers, but Helix took that concept and applied it specifically to Sitecore. This provided a structure extremely suitable for creating and maintaining solutions of any size, and steered developers to producing cleaner and maintenance-friendly code. I would highly recommend reading through Helix for this information, but here is the short version for those of you who just want a taste.

Sitecore describes three separate layers, as depicted below.

  • Project Layer — this is the layer where the project itself is implemented. It brings together both the feature and foundation layers into an actual cohesive output. It is the most unstable layer.
  • Feature Layer — this layer contains just what you think it would; features. Helix uses examples like news, articles, promotions, and website search, but I’ve also implemented things like navigation in this layer. One very important thing to remember is individual features cannot depend on each other.
  • Foundation — this layer, as the name suggests, lays the foundation for your solution. It’s the most stable of the three layers and changes made to it will likely impact other layers in the solution.

DEG created a plug-and-play feature layer to choose what featured it wanted to pull into projects.

DEG has a Sitecore accelerator that we use on our projects named Elision. We have been using it for a few years now and have also made it open source for others in the community to use. Once I read about Helix, I immediately wanted to implement its layer principle in Elision.

During our planning phase, my team and I noticed there didn’t seem to be a great way to pull individual features into a client solution. We wanted to create a plug-and-play feature layer that would allow us to pick and choose what features we wanted to pull into our projects and avoid bringing in the ones that were not needed. We also identified there were some features that would have a great degree of volatility per project, like navigation. The underlying server-side code would, for the most part, stay the same, but the client-side assets would be different almost every time. We chose to solve both of these problems by implementing our own unique take on Helix’s feature layer.

We decided to create two different types of features, template and library, both of which would still live in the feature layer. This is an approach that has worked well for us, and we feel might work well for other people, too.

Template features provide base functionality to get to 80 percent of the way to the client solution.

Template features — features that are brought into the client project as source code. These are features like navigation that will have a high degree of volatility per project. The goal of these features is to implement the boiler plate code and provide base functionality to get us 80% of the way to the client solution. The 20% that is left should be client-specific and implemented after the feature has been brought into the project.

Library features — features that are brought into the project as references, like any other NuGet package. These are features like sitemap.xml that can, for the most part, be used out of the box. Any customizations that need to occur should be done via adding steps to pipelines, overriding methods, etc.

The final piece of the puzzle was to figure out a way to bring these template features into our projects as source code. Since Elision’s foundation layer and library features were brought in via NuGet, we wanted the template features to behave the same way. It turns out NuGet gives you the ability to run custom Powershell scripts on a few different occasions, including when your package is initially installed and when it is deleted. Structuring your .nupkg files in the following way will allow you to take advantage of this.

There will be a separate blog post to cover how this is setup in more detail, including the Powershell scripts we used, so stay tuned! Until then, check out the demo below of it in action.

 

What do you think of this approach? Love it? Hate it? Let us know! Also be sure to check out Elision, our implementation of Helix, on GitHub.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comments