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.
We will start with pipelines – this is a personal bugbear of mine. Imagine if you will – an automatically generated xml sitemap for search engines, or saved content being automatically tagged with some fantastic auto-linking strategy that marketing absolutely MUST have. Developers (in some cases wrongly) choose to implement a pipeline to serve such functionality.
Often, they miss out on things like:
- The fact that the particular pipeline in question will fire on the content delivery servers when there is no need to
- The effect on the Page Editor experience and how it interacts
- More fundamental stuff – for example THIS CODE IS GONNA EXECUTE ON EVERY PAGE LOAD
- And more importantly than the last point – NOT EVERY ITEM IS A PAGE 😀
I have seen developers add code to event handlers that traverse the entire Sitecore tree on every publish, I have seen code that traverses huge structures of products to provide navigation within the site.
I guess consider this – implement your code to affect as little as possible, if it is only required for a single / handful of pages – a sublayout / rendering might be the key. An ‘auto-link’ to an item – perhaps a command on a button for the user, or a workflow might suit better (it may certainly be more targeted)? Maybe also consider the possibility of a rule to perform an action? There are hundreds of ways to skin the Sitecore cat!
If it is required to be a pipeline – PLEASE PLEASE ensure that it is only affecting the correct scope and PLEASE PLEASE ensure that you are not killing the site to do so.
I always remember the phrase ‘Embrace and Extend’ coming up during training for Sitecore. It’s something I remember just as much from the Umbraco development of my past, hence the title – ‘Don’t Fight The Framework’ (from the umbraco day’s). I guess you can sum it up as this – if it require’s you to REWRITE sections of Sitecore to implement, its probably not the way you should be doing it. Let’s face it, there are hundreds of us developers who have managed to implement fantastic solutions using (mostly) Sitecore’s out of the box functionality. (We all think we know best :D)
To clarify here, I am not so much talking about the use of Glass / Synthesis or whatever other ORM you might choose or even the use of Lucene (and therefore Lucinq – shameless plug) to provide fast searching, and to make up for the poor performance that can be found in tree traversal. I am on about the fundamental stuff.
How many Database ORM frameworks for example does the world need before a developer will consider one of the existing one’s fit for purpose? – I have seen so many ‘home-grown’ solutions, I have to question – ‘What was so wrong with N-Hibernate, Subsonic and all the others (missing off EF here for a reason ;)) that the developers felt the need to write their own, rather than simply use ADO.NET.
Let’s extend this and take for example (as I have seen on a few occasions now), the idea of implementing a developer friendly Model View Presenter based framework on top of Sitecore. I have seen solutions where the control of presentation is done from fields within a content item and then the MVP framework interpret’s them in order to render them to screen. In one particular example, it simply give’s Sitecore a single sublayout as presentation. This is a classic example of (in my opinion) where developer’s have thought that their solution is better than the vendors (before you start on Lucinq – it’s wrapping Lucene to make it easier not replace it 😉 ). I agree that it is a developers choice to write such solutions. In this case for example, it has prevented upgrades, use of page output caching (often our temporary get of jail card), the page editor & sufficient Sitecore support. It has also meant that near every single page in their solution is a mass of > 100 fields where the vendor continued to add fields for use cases specific to only a few pages. Ultimately – it has lead to an unhappy client & a ditched vendor. Worst thing is, I know of 3-4 other solutions off the top of my head that are using this or similar frameworks with similar issues not all from the same vendor.
A good example of this on its head might be to use the Factory implementation Sitecore provides us with to allow injected dependencies for controllers. We are still using what Sitecore gives us, but trying to use it to allow modern best practice of IoC, thus (hopefully) in the future, giving us minimal headache in continuing to run our sites and hopefully maximum test-ability.
So here we have a great examples of what to do and not to do in a robust, scalable, long term solution, so what can we do better? In short this is simple and adhere’s to Sitecore’s recommended best practice which is simply – Embrace what the framework gives you and Extend it using the many great ways Sitecore have given us to do it – Pipelines, Commands, Renderings and many more.
Learn the presentation
Quick point on this I feel as I may well extend it into another post – developers should really take the time to learn the presentation engine in Sitecore, it is incredibly powerful and I have met quite a few developers (including myself on occasion) who make bad decisions through simply not knowing the product. Simply put – as a base, you should try to understand the following well:
- Datasource Templates
- Rendering Parameters
- Rendering Parameter Templates
- Conditional Renderings
- Rules engine basics
- Standard values – in particular presentation & also using them to give differing versions of the same components
Ok – so I have covered off a few points (which in turn has given me a hundred others), but at its core, the message is simple – and I will base this on the cheesy but true quote of ‘Be Like Water’. Consider Sitecore as the river, you can help manipulate it down the mountain to help water the crops, but don’t try to stop it or eventually it will find it’s way without you and potentially come crashing down around you.
This article is part of the Don’t Fight The Framework Series