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“.
- The Project layer provides the context of the solution.
- The “website” project in visual studio
- 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.
- 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?
- Most stable layer in the solution. Code does not change often.
- Change in a foundation module can impact many other modules in solution.
- 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.
- 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.
- /sitecore/templates/[Project|Feature|Foundation]/[module folder]
- Always use MVC, Webforms is strongly discouraged.
- Avoid having any code in base layout .cshtml file
- Instead insert renderings via placeholders that contain the logic
- Avoid having any code in base layout .cshtml file
- 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.
If you want to learn about Helix, I recommend:
- Official Documentation: http://helix.sitecore.net/
- Sitecore Habitat on GitHub:
- Video Introductions: https://github.com/Sitecore/Habitat/wiki
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!