Sitecore Helix: Workshop and Knowledge Share Useful Notes

Posted by

This past March I attended the Sitecore Partner Helix Two-Day workshop in Burlington MA. This was a hands-on development workshop where myself and about 10 other Sitecore developers where introduced to Sitecore Helix and Sitecore Habitat. It was a mix of presentation and hands-on coding adding new module to the Habitat site. I thought this workshop was extremely useful and learned a lot about Helix architecture.

So fast forward a few weeks to mid-April. My boss asked me to present what I learned at the Helix workshop to Verndale’s entire engineering team. Verndale is planning to build all new sites using Helix architecture, and I was honored to be able to present to the team.

Below you can find some excepts from my knowledge share presentation:

What is Sitecore Helix?

  • Helix is a set of overall design principles and conventions for Sitecore development.
  • Helix was created by Sitecore themselves and is a recommended best practice.
  • The main goal of Helix is to organize and reduce decencies, while making your Sitecore project as easy to create, test, extend and maintain as possible.
  • However the goal of Helix is not re-use, its maintainability.
    • Reuse is a nice side effect but not the main goal.
    • Your site is easier to maintain or bring in new developers since it follows a standard architecture.
  • Specific & concrete conventions for how Visual Studio projects are organized.
    • No more guessing where code should go – Helix spells it out very clearly.
  • No more monolithic projects: Helix architecture will keep the solution clean and decencies organized.

What is Sitecore Habitat?

  • Sitecore Habitat is an example Sitecore solution build with the Helix Architecture.
  • Available on GitHub, Habitat is a open source, free to download, use, or fork.
  • Out of the box, Habitat uses unicorn, a free framework for serializing Sitecore items.
  • Fork of Habitat available with TDS instead of Unicorn.
  • Shows developers to see how Helix is applied and experience a project based on these principles.
  • Provides an examples of
    • Sitecore Architecture: Templates, Layouts Content
    • Visual Studio Solution Architecture
    • File System Conventions
  • Habitat is an extreme example of helix architecture. It is not meant to serve as a “basesite“.  

Helix Layers

helix layers

Project Layer

  • The Project layer provides the context of the solution.
  • The “website” project in visual studio
    • Base layouts, CSS, structural JavaScript
  • Unstable & Concrete
    • Unstable: code is changing a lot day to day
    • Concrete: Little to no abstraction
    • E.g.: Each time there is a change in a feature, a new one is added or one is removed, then this layer will typically incur a change.

Feature Layer

  • The actual features of your website.
  • Tons of projects, each responsible for a single objective in the business domain.
    • Blog: Feature.Blog
    • News: Feature.News
    • Account: Feature.Account
    • Don’t create a separate project just for “top level navigation” and also “sub nav“, Should be in a single navigation project.
  • Flexible & Concrete
    • Unstable & Flexible: Code changes frequently.
    • Concrete: Uses Controllers, Models and Views to render a module
  • Uses interfaces/abstractions/services from the Foundation layer

Feature Layer – Mistakes to Avoid

  • Do not make feature projects like “SearchBox”, “SearchResult”.
    • Instead, create a single Project for Search: Feature.Search
  • Name of the feature should be technology agnostic.
    • E.g. never call a project “Feature.SolrSearch”
  • Generic Module likes Utilities or Helpers often indicates that the module has too many responsibilities
    • Do you really need a helper or utility class?
    • Can you abstract it in some way?
    • Can you make it a Foundation module?

Foundation Layer

  • Most stable layer in the solution. Code does not change often.
  • Change in a foundation module can impact many other modules in solution.
  • Purposes
    • Sitecore code, base templates, helpers
    • Solution Wide modules. such as WFFM
    • Shared code used by two or more feature modules
  • Abstract: A foundation module should not be specific to a single feature.
    • Should be IoC compatible.
    • IBlogRepository, IAccountService, etc.

Visual Studio

  • Lots of Solution Folders and Projects
  • Your architecture should always have higher priority than any tool or technology.
    • (Don’t compromise your solution architecture a certain package or framework that doesn’t lend itself to your architecture / Helix)
  • Only with sincere thought should you deviate from Helix conventions.
    • Deviations or exceptions will most often lead to technical debt and instability or lack of flexibility.
  • For multi-tenant or multi-site solutions, each tenant/site should be its own visual studio solution, that references common foundation modules.


  • Interface template
    • Defines the content fields for a module.
    • Examples: _Link, _Hero
  • Page Template
    • Makes up the pages of the website. Derives from interface templates and has a presentation layout.
  • Datasource Template
    • Items from this template are referenced by renderings as a datasource. Derives from interface templates but has no associated layout.
  • Settings Template
    • Used for lookup items for fields or to hold fields to configure the business logic in modules
  • Folder Template
    • These templates are used for the folder items that make up the scaffolding of the content structure.
  • Structure
    • /sitecore/templates/[Project|Feature|Foundation]/[module folder]

Page Layout

  • Always use MVC, Webforms is strongly discouraged.
  • Layouts
    • Avoid having any code in base layout .cshtml file
      • Instead insert renderings via placeholders that contain the logic
  • Renderings
    • Business logic NEVER in views. Views are for rendering.
    • Avoid statically binding renderings in sub-layouts, but rather bind all renderings to layouts via layout definitions and placeholders.
    • Partial views should be prefixed with underscore (_) to separate them from the views references through Sitecore items or controllers.

More Information

If you want to learn about Helix, I recommend:


I hope you enjoyed the excepts from my Sitecore Helix presentation. Please share any thoughts with me in the comments.

I want to attribute / point out that a few notes above where taken from or heavily inspired by the official Helix documentation. If it ain’t broke, don’t fix it!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s