Belangrijke mededeling over deze pagina:

Deze pagina is niet beschikbaar in het Nederlands en daarom wordt de Engelse versie van het artikel getoond. Dit komt vooral voor bij technische artikelen.

Sitecore 7.5 is about to be released this week and it comes with a bunch of really neat features and improvements. I've had the chance to start developing with an early release of 7.5 few months ago and it has been a pleasant experience so far. Now, I could blog about the most obvious new feature (xDB), but I think that has been covered enough already in other MVP blogs and at the Sitecore Symposium. Instead, I'd like to point out a little hidden gem in Sitecore 7.5 that not many people have noticed yet (according to a live poll during the MVP summit in Barcelona).

Sitecore 7.5 ships with a new binary named Sitecore.Abstractions.dll
This offers you abstractions for some parts of the Sitecore API that are implemented as static classes in the kernel. Being static classes, there is no way to run unit tests on code that is depending on them without running from within a Sitecore application.

If you ever tried unit testing in Sitecore, you will know that if you call Sitecore.Configuration.Settings.GetSetting("MySettingKey"), for example, it will always be null.
Because the unit test does not actually load the Sitecore application, it will have no configuration in memory and thus no access to settings.

The preferred way of calling this API logic would be through services/providers that can be injected into your own classes using dependency injection. But being part of the kernel, Sitecore is not able to simply rewrite them as it would break compatibility.

You can work around this issue by creating wrappers that implement interfaces and call the static parts of the API. This way, you can inject the wrappers in your own classes to call the API and mock the interfaces of those wrappers in your unit tests. Here is a quick example to explain what I mean by that:

public interface ISettings
{
    string GetSetting(string name);
}

public class SettingsWrapper : ISettings
{
    public string GetSetting(string name)
    {
        return Sitecore.Configuration.Settings.GetSetting(name);
    }
}

// When your class needs to call this API method, it would look like this:
public class MyAppLogic
{
    private ISettings settings;

    public MyAppLogic(ISettings settings)
    {
        // This is where the settings wrapper is injected.
        // You would inject a mocked version when unit testing.
        this.settings = settings;
    }
    
    public void DoSomethingWithSettings()
    {
        string result = this.settings.GetSetting("MySettingKey");
    }
}

This is exactly what Sitecore is providing now with Sitecore.Abstractions.dll!
It saves you the trouble of creating wrappers for the most crucial parts of the API yourself.

Here is an overview of the wrappers and the part of the API they are wrappings:

Wrapper class Interface Wraps
AccessRightWrapper IAccessRight Sitecore.Security.AccessControl.AccessRight
CorePipelineWrapper ICorePipeline Sitecore.Pipelines.CorePipeline
EventManagerWrapper IEventManager Sitecore.Eventing.EventManager
EventWrapper IEvent Sitecore.Events.Event
FactoryWrapper IFactory Sitecore.Configuration.Factory
RuleFactoryWrapper IRuleFactory Sitecore.Rules.RuleFactory
SettingsWrapper ISettings Sitecore.Configuration.Settings
TranslateWrapper ITranslate Sitecore.Globalization.Translate

Want more wrapping?

There are more static parts of the API that you might want to abstract. Kern Herskind has shared a proof of concept of a T4 template that can generates wrappers for static and non-static classes. Although it's not thoroughly tested, it seems to work quite well and is easy to customize for your needs. You could use this POC to generate your own wrappers for parts of the API that are not included in Sitecore.Abstractions.dll

1 Reactie

Plaats een reactie