Nat and I have worked together for quite a while now and Don’t Fight the Framework has become a running meme between us almost since day one.
In this post I thought I’d take a side step on this and talk about an example of going against best practise. Admittedly, best practise is often convention based so it can be hard to know what is the right and wrong way. As in many cases there is the right way and the better way, which is usually the case in Sitecore.
Before I continue, I want to point out that there is nothing wrong with creating event handlers for saved and published events. Running code from the rules engine, moving items, creating items etc are all good examples (and I use them). But you must be aware of the consequences and code accordingly. That said, they can also used for the wrong reasons as we will discover.
After reading Simon’s post on Sitecore Template Inheritance and continuing the vein of my thoughts on implementation starting with my thoughts on Sitecore Visual Studio solution structure I thought I would write a few words on when / why we might choose to extend Sitecore in different ways.
So many times I hear from clients about how Sitecore is running slowly, or Sitecore takes ages to save something. I end up repeating myself so often – ‘Sure, Sitecore has some issues in some area’s, but for the most part, if Sitecore is running slowly, its cause the development isn’t right in some way!’. In short, Sitecore has many sites in the wild with over 200,000 items (per language) of content running absolutely fine and dandy on small server clusters. Sitecore CAN do it, if it can’t there is a reasonable likelihood that in fact the developer hasn’t thought enough about what they are doing and whether its the best way to do it.
I am sure there have been dozens of similar posts over the years, but I thought I would run through my approach to structuring a visual solution to allow it to get along easier with Sitecore.
Firstly, I will come out and say the following: The Microsoft web publishing tools in visual studio are fine for small sites & solutions. Sitecore starts its life with > 8000 files out of the box. I personally don’t enjoy adding all of these files to a visual studio solution and don’t feel it is necessary or beneficial :D!!
Also – credit where its due, my idea’s have been inspired over the years by a mix of working with umbraco (and their best practice), a blog post from Mark Cassidy.
Ok, so this will probably seem like a rant at first, and to some it will be preaching to the converted, but I cannot count the number of times that I have seen this approach in code.
if(item.TemplateName == "my template")
if(item.TemplateID == new ID(""))
In Sitecore, we have the great strength and flexibility that is template inheritance, and multiple inheritance at that. Most of the components we develop often contain logic that checks for the availability of field values and the like, and lots of code I have seen created by developers will have direct references to a particular template – please don’t :D.