In case you weren’t already aware, Sitecore is an object based database (the item). The result is that everything is expressed in the database as a ‘thing’ with fields, whether shared, unversioned or versioned. Whether we publish, make a package or replicate our data, we need to uniquely identify each one of these items and so use a UniqueIdentifier as our ID type.
Whilst this has some advantages, when it comes to Sql Server it has a few performance issues when used as a primary key. We can’t rely on a sequential ID (whether numeric or a psuedo guid) due to potential collisions between systems and so we have a clustered index on a random data set.
So – in this post I will cover my latest (and somewhat marmite) solution to the issue of managing dependencies when your clients insist you use the IoC container of their choice.
Many times in my development career I have had to switch the use of IoC containers due to the client having defined standards on what they would like you to use. So far, I have already had the opportunity to implement sites using Autofac, Ninject, Windsor & Unity. I fully expect there will be more!
In addition to this, I have a number of modules now available that I have deliberately avoided using a DI framework due to the above (it is a personal bug bear of mine for example that Sitecore’s social connect module ships with Ninject).
For all of the reasons above – I have created Agnostic IoC. It is a simple module that handles the instantiation of IoC containers and allows your code to rely on its own IContainerManager to resolve your dependencies.
Some time ago I decided that Autofac was my IOC of choice. After spending a few years using Unity I knew I wanted more and, after evaluating a few libraries, Autofac fitted how I work.
Aside from the usual property and constructor injection stuff we would expect from any IOC library, Autofac has quite a few additional features that can make coding life a lot easier. And in less lines of code.
One thing I love to show people who have used IOC for a while is my use of delegate factories.
The wiki post from the Autofac project is here: https://github.com/autofac/Autofac/wiki/Delegate-Factories.
I think the title says it all!
Let components create instances of other components without hand-coding factories.
So, in short, we can use Autofac as a factory and take a dependency on that factory instead of the type itself. This is quite powerful as it means we can create instances of our dependency within our component as needed.
Ok, so – Cardinal Rules Queries has recently had a beta release, you can find it here. It allows you to leverage the power of the rules engine in Sitecore to build queries based on Lucene.Net, and if you choose – other search tools. Please see my initial post Sitecore Rules Queries Pt I for a bit more information.
Following on from this, I thought I would write a quick article on how you actually use it in code. Please note this is subject to change, but is correct at the time of posting.
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.
Inspired by Nat’s post on inspecting what templates an item is inherited from, I wanted to post my own thoughts on how you would use this in practise. Often when I review template structures in Sitecore I get a feel for how well the template developer has of Sitecore presentation and ensuring flexibility.
A good practise that I advocate in these review sessions is to consider templates as abstract collections of fields. We then extend this concept to consider anything we make a content item out of as something that groups abstract groups of fields together.
What is important, here, is that I haven’t mentioned inheritance. As Sitecore is based on .NET and the single inheritance model, developers can often think of Sitecore inheritence in the same way.
Ok, so I finally managed to get my MongoDB hat back on recently and first thing that struck me is that I forgot how much I love it as a product, the driver is easy to get to grips with, its a doddle to set up and hyper fast :D.
Below I have listed a starting point that I have been working on to serve the latest version of content from Mongo, in part this is to help out in the content editor (and in particular, that item.GetChildren() causes the default item provider to return the latest version from the database, but I expect to extend this to be able to serve all of the web content from such a provider.
This post at present is the basis of a working idea that I have been playing with, but I think with refinement (and certainly until Sitecore provide us a full blown MongoDB based version) it might have mileage to enable us to squeeze a little more performance out of our existing implementations.
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.
During the course of the Sitecore installations (versions 6.2 – 7.2) I have been involved with, I have been asked to allow users to be able to select the results of their data for themselves. In later versions Sitecore have achieved this using the newer Search dialogs. I will come out and state that I haven’t really found the search dialogs too helpful as a user myself, and that I don’t see the content editors using them all that much either.
It has struck me since I first began using Sitecore that the rules engine could be an obvious potential solution to this issue. The basis being that you create a ‘query’ item, this item is then used as a datasource / basis item for your renderings (or sublayouts in older installations). I also considered the idea of combining the rules engine with Lucene / Solr in order to retrieve results based on the selection the user makes – after all, that’s what we are kinda doing as developers in any case.
I first started messing with the rules engine – shown in this post Searching with the rules engine in Sitecore. This was great and really started to show the potential. I also realised quickly that users would need to be able to test their queries from within the engine, so after a little work, I settled on a dialog that looked like this:
Just for fun – the core engine that drives this is using a simple visitor pattern and could be utilised for other data – I am currently also experimenting with my mongo L2 cache with extended linking 😀
In the next post, I will describe how to use the results of your rules queries in renderings / sublayouts or other tasks.
EDIT: For those who dont know, you can find Rules Queries for Sitecore here on Github
In this post I will be looking at how to drive a lucene search by using the Sitecore Rules engine.
Pretty much since I started using Sitecore, I have found that Lucene has been the get out of jail when it comes to performance. In fact, I can’t remember the last time I used Sitecore queries or the item axes. As a developer I have always been happy to write such methods as GetDescendants(ID itemId, ID templateId).
What about giving this power to the user though?
The rules engine in its default form is a great tool but executing a rule against a bunch of items becomes a iterative process and often can carry a performance penalty. This got me thinking – could I use the rules engine to drive the Sitecore Search Layer?