Dependency Injection with Sitecore

I frequently see Sitecore implementations that use no form of Dependency Injection (DI) or perhaps worse still lean on a Service Locator Pattern to build up component dependencies. When I tweeted about this situation some of the responses I got back really surprised me.

Wondering why more #sitecore web forms devs don’t use an IoC and employ DI. It’s 5 minutes work to get property injection going.

— @KevinObee .. October 26, 2013

I’m not sure whether there is a lack of awareness about DI around some areas of the Sitecore developer community or, as some of the responses to the tweet suggested, we have more than our fair share of Dark Matter Developers.

In this post I’ll try to give the briefest overview of what DI is, and show just how simple it is to implement in a Sitecore solution.

Glimpse for Sitecore

Welcome to a new era of server side diagnostics with Sitecore. In the past we had the following tools to help us identify performance issues with our Sitecore installations:

• Sitecore Log Analyzer (SCLA)
• ASP.NET Trace
• Sitecore Debugger
• Sitecore Admin pages
• Sitecore Rocks

These tools could be used in circumstances where it is not possible to attach a debugger or application profiler like the ANTS Performance Profiler to a running web application. No there it’s time to add a new tool to this list, that tool is Glimpse.

Fixing up Sitecore.Nuget connections

This post aims to document an issue and workaround for something that I spotted when working with Sitecore.NuGet to install Sitecore enabled NuGet packages.

For the uninitiated the following extract explains the idea behind these packages.

Sitecore.NuGet allows NuGet packages to be installed in a Sitecore solution, including Sitecore items.

A Sitecore NuGet package that contains items requires the Sitecore Rocks Hard Rock web service installed on server and that the Visual Project has been connected to the Sitecore installation.

The open source Sitecore.Mvc.Contrib project uses Sitecore.NuGet to package up and install Sitecore content items. In order for these packages to install the Visual Studio project has to be connected to a Sitecore site. In itself that is not a problem, simply right click on the project file in the Visual Studio Solution Explorer, select Sitecore -> Connect to Sitecore Explorer Connection… on the context dialog and connect to a Sitecore website. This will add a connection to the Sitecore Explorer as shown below.

After configuring the project you should be able to install a Sitecore.NuGet package like any other.

PM> install-package sitecore.mvc.contrib

The regular files within the package get installed as expected and then a nasty surprise pops into the package manager console output.

Successfully added 'Sitecore.Mvc.Contrib 1.0.1' to Website.
 install-items : A connection to "sc66contrib (sitecore\admin)" was not found.
 At C:\Websites\sc66contrib\packages\Sitecore.Mvc.Contrib.1.0.1\tools\install.ps1:19 char:3
 + install-items -toolspath $toolsPath -project $project -dte $dte;
 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : NotSpecified: (:) [Install-Items], InvalidOperationException
 + FullyQualifiedErrorId : System.InvalidOperationException,Sitecore.NuGet.Installing.InstallItems

I’m obviously not alone in suffering from this issue:

@KevinObee @TheRocksGuy this. If you’re using local IIS sites in latest rocks it’s busted anyway.

— Kam (@kamsar) August 2, 2013

Hiding XDT Transforms from Sitecore

Sitecore ships with a very useful web.config patching feature that allows everything within the element in the configuration file to be modified and extended. It is a best practice recommendation not to modify the web.config file directly but instead use customised configuration files located within the App_Config\Include folder to overlay the modifications that your solution requires.

Rather that regurgitate information on how to use the web.config patching mechanism I’ll suggest instead that you start with John West’s post All About web.config Include Files with the Sitecore ASP.NET CMS for a definitive way into this subject.

web.config transform files

Developers working with ASP.NET web applications outside of the Sitecore ecosystem are likely to be performing their web.config transformations using Microsoft’s XDT transform syntax. The popularity of the XDT engine is such that it has recently be issued as a NuGet package so that it can be shipped with third-party products. Whilst on the subject of XDT transforms it would be worth pointing out the Slow Cheetah Visual Studio extension for those new to the area. This package enables you to transform your web.config or any other XML file based on the build configuration and preview the outcome – simply invaluable.

MVC Areas in Sitecore

Areas have been a part of ASP.NET MVC since ASP.NET MVC 2 shipped in 2010. This walkthrough article from MSDN sums up why areas are useful in MVC web applications. A brief extract follows:

To accommodate large projects, ASP.NET MVC lets you partition Web applications into smaller units that are referred to as areas. Areas provide a way to separate a large MVC Web application into smaller functional groupings. An area is effectively an MVC structure inside an application. An application could contain several MVC structures (areas).

For example, a single large e-commerce application might be divided into areas that represent the storefront, product reviews, user account administration, and the purchasing system. Each area represents a separate function of the overall application.

The release of Sitecore 6.6 saw the introduction of support for MVC and the Razor view engine within the Sitecore CMS. It wasn’t long before a question popped up on stackoverflow asking how to wire up a Sitecore Controller Rendering to a controller located within a MVC Area.

Hopefully this article will provide some answers for those wanting to use MVC Areas with Sitecore and highlight a few of the subtleties that currently may not be so well documented.

Doing the Simplest Thing

HTTP 304 response handling in Sitecore MediaRequestHandler

Whilst testing a Sitecore 6.1 site due for release Firebug highlighted some unexpected behaviour from the Sitecore Media Request Handler which takes care of responding to requests for items held in the Sitecore Media Library. Media library items were being returned in full every time that they were requested, each returning a HTTP 200 response status code.

Further digging with Lutz Roeder’s excellent Reflector tool showed that the If-Modified-Since request header field was not being responded to correctly by the MediaRequestHandler. The If-Modified-Since request header is a HTTP-date value whose time component is in the format HH:MM:SS (i.e. no milliseconds). This header field value is used by the Modified method within the MediaRequestHandler to compare to the System.DateTime value that the media library item was last updated. As a System.DateTime value includes a milliseconds component the equality check fails for the majority of media library requests and as a result the item is downloaded to the browser in full.

Sitecore have confirmed that this is a known issue and something that will be fixed in a forthcoming release. In the meantime it’s not difficult to patch in a modified HTTP handler to respond to media library requests and implement HTTP 304 response handling appropriately. Alex de Groot has a good article on his blog that explains how Sitecore interacts with HTTP handlers for media handling.