What Sitecore Helix Doesn’t tell you!

Posted on

Sitecore Helix is there for a good reason. It tells you how to organize stuff such that it looks smart and it’s maintainable. You can see the sample implementation in Sitecore Habitat but you might miss a few things that I would like to emphasize here.

You will have a Taxonomy Foundation Project – Regardless!!!

If you like to be cool and all, you say, each feature should be Atomic and therefore holds it’s Templates, Modules, Logic, etc . Yes! right! Brilliant! But then Search happens. Take this scenario. You have a feature called Articles which obviously does lot’s of things and then client wants to make those Articles searchable. These are two different features and you don’t want to write Search related code in your Articles feature. Search needs access to your article Templates and if you are smart enough you are keeping your queries in the Foundation level. Since Foundation level shouldn’t reach out to Features, you have to relocate your templates down to Foundation where multiple features and/or foundation modules can access it.  Taxonomy project is the grave yard of atomic Features and the idea of reusable component. It’s ugly but can’t be avoided. If you have a work around this, buzz me.

Have one Item repository and STICK TO IT.

Ideally, in your Foundation Level you should have ItemRepository, DictionaryRepository, LogRepository, and Caching. These all are the single point of access to Sitecore. Your features should only use these foundation Modules to get Datasources, Items, Settings, and basically every data you need from DB. Having these classes centralized simplifies your life in the future. The best example that supports this approach is changes in Glass Maper. The new Glass Mapper (Sitecore 9.2+) uses IMVCContext and IRequestContext instead of ISitecoreContext. When you upgrade your solution to a new Sitecore, you will have to refactor only one place and that is the ItemRepository and no other feature needs refactoring (Voila). Additionally, your unit testing will be much easier.

DI could be simpler

If you wan to use Sitecore DI, you should create a config file or a class to register each service. This just doesn’t make sense to have extra class or extra files in every single project. Create a foundation class that is in charge of automatic registration of  all the services. Sitecore habitat has the right code.

Small but Important Tips

  • Keep a good habit and a Clean code. Have rules for Field, Properties, Local variables, Controllers, Services, etc. They should have a naming convention. Project names should have same naming patterns. There are lots of Code Analyser out there that can help you with that.
  • Get aligned with your FE developers. Don’t let them freely create folder in Feature/Foundation folder.
  • Do not create VS project for every small features. You don’t want to wait minutes before your VS can open your solution or take hours to build it. Lower the number of Project, the faster it will be. Therefore, try to compact related features into the same project and maybe you can create a General Project for small independent features.

Leave a Reply

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