Alternatives to Sitecore Habitat

I previously blogged about the main themes of the Helix principles, and how each of the main aspects of Habitat achieves the aims of Helix. Of course, Habitat is only one interpretation of Helix - but unfortunately it looks like copying Habitat has become a common way of implementing a Helix solution. Habitat is a coherent implementation of the Helix principles, but it is meant only as an example. In this post I take a look at way of changing one of the “dominant” aspects of Habitat to arrive at a different implementation approach.

 

Fractal picture

 

How many Visual Studio projects?

In my view, the most drastic aspect of Habitat is the usage of one Visual Studio project for each Helix module, meaning that as your solution grows and evolves there is no upper bound on the total number of projects/assemblies. This may cause a number of problems, such as:

Contrast the downsides against the upsides, and you might find you’re not getting a return on your investment in the VS project-per-module approach:

  • The VS project-per-module approach helps enforce the Helix layer dependencies between module code. However, it’s arguable that the more numerous dependencies (or at least the most insidious dependencies) are the more implicit dependencies - e.g. between Sitecore items and code, between code and config, and between CSS/JavaScript and HTML. In addition, there are other approaches to enforcing code dependencies without resorting to the Visual Studio project structure, for example take a look at https://www.hhog.com/blog/sitecore-helix-fxcop-rules
  • The VS project-per-module approach also means your modules are separated on the filesystem (i.e. all module artifacts will end up inside a containing folder specific to that module.) Also module artifacts are clearly separated for the developer in the Visual Studio UI, as a consequence of the project structure. While this is an upside, as it helps enforce the conceptual module boundaries with “physical” boundaries, it needs to be balanced against the potential downsides
  • The VS project-per-module approach allows the option of having different “views” on the overall implementation by creating extra Visual Studio solutions which contain a subset of the VS projects from the "master" solution. These could be split by business area or by team, for instance. This seems like more of a “nice-to-have”, unless you anticipate your solution getting really large
  • Similarly to the last point, if your Sitecore instance ever needed to be split up into two or more smaller instances, the VS project-per-module approach would make this split a lot simpler - you would “simply” need to work out which Helix modules need to live with each new Sitecore instance and create new solutions for each subset

Allowing your Helix modules to live across multiple Visual Studio projects

If you have decided you don’t want to go down the VS project-per-module approach for your Helix implementation, here are a few suggestions of different approaches you could take, and some thoughts about the implications of those decisions. For all of these approaches I’m assuming that Helix module separation is still present in some form, and the Helix dependency rules are still respected: solution folders can serve as containers for module artifacts, rather than Visual Studio projects.

Ask yourself the following questions to work out which direction you might want to go in when thinking about your Helix module -> VS project mapping:

  • Do you want to group your non-code artifacts?
    • This kind of setup would mean you can develop inside the web root with minimal tooling support. For example, you could use a “Website” VS project which contains all config, CSS, JavaScript and views. All code could live in other VS projects. With this structure, a Helix module may have a presence in multiple VS projects (e.g. its config in “Website” and code in another project) The file naming and subfoldering conventions can be similar to that used by Habitat, so it’s still clear which artifacts belong to which Helix module, but you might also want an extra level of folders named after each module (e.g. to prevent Foundation/Feature/Project folders with a huge number of config files/view files/whatever… remember to amend your RazorViewEngine “ViewLocationFormats” if you do this for your views)
  • Do you want to share any of your Helix modules with solutions belonging to other Sitecore instances?
    • This can be tricky due because you will usually require more strict versioning; it probably makes sense for the shared functionality to live in a separate VS solution/source control repo, and to be integrated with its consumers via an internal NuGet feed (so that consuming solutions aren’t forced into the same release cadence as that of the shared module.)
  • Do you have a separate team of front-end developers who would like the VS solution structure to fit with their preferred ways of working?
    • If UX developers want all their assets in the web root, the first point (“group your non-code artifacts”) covers this. Or if you’ve opted to develop outside of the web root and are already “publishing” the files of various VS projects into the web root, you could choose a dedicated VS project for CSS/JavaScript/etc
  • Can your Feature/Foundation modules be grouped into logical subsets?
    • If so, you could consider opting for one Visual Studio project per “group”. Alternatively, you could opt for just one VS project for each entire layer, with solution folders for each module name containing your code (and the code namespaces matching this convention). For either option, if you’re including non-code artifacts then these projects will be web projects rather than class libraries, with top-level styles/script/views/config folders split into subfolders by module just like in Habitat
  • Are there any other factors specific to your situation?
    • Remember, the Helix guidelines are only there to facilitate development productivity. Don’t lose sight of your ultimate purpose by getting too bogged down by the details of Helix. Break the rules where it’s pragmatic to do so.

In Conclusion

Ultimately you’ll need to weight up the pros and cons relative to your specific implementation and your team to work out how you should implement Helix. Sitecore will eventually be publishing some official “non-Habitat” VS solution structure examples, so keep an eye out (take a look at https://github.com/Sitecore/Helix.Docs/issues/21 for the related discussion.) I’m sure that some “winning” solution structures (and supporting tooling) will emerge over the coming years, as the community continues to try and pit the Helix philosophy against the real world.