Dependency injection

11 min

Dependency injection (DI) in Optimizely Content Management System (CMS) is based on the DI framework in ASP.NET Core located in Microsoft.Extensions.DependencyInjection API. CMS is configured to use the default DI implementation in ASP.NET Core. The required code in Program.cs to connect the DI framework in ASP.NET Core with CMS is the call to the extension method ConfigureCmsDefault() as in the example below:

public static IHostBuilder CreateHostBuilder(string[] args) => 
    Host.CreateDefaultBuilder(args)
        .ConfigureCmsDefaults()
        .ConfigureWebHostDefaults(webBuilder => {
            webBuilder.UseStartup<Startup>();
        });

Custom dependency injection frameworks

To use a different DI framework than the built-in, you should replace the call to ConfigureCmsDefault() with a call to UseServiceProviderFactory, passing in an instance of ServiceLocatorProviderFactoryFacade, that should encapsulate the actual implementation to use. The following example shows how to configure the application to use Autofac (given that there is a reference to the Autofac NuGet package):

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .UseServiceProviderFactory(context =>
            new ServiceLocatorProviderFactoryFacade<ContainerBuilder>(context,
            new AutofacServiceProviderFactory()));
        .ConfigureWebHostDefaults(webBuilder => {
            webBuilder.UseStartup<Startup>();
});

Implicit registration of services

The following example shows how to use implicit registration by using the ServiceConfiguration attribute makes it easier to read classes because the registration is done in the same class as the implementation. The code is an example of registering a service as a transient service (instances are created every time) or as a singleton service (a single instance is re-used).

public interface IService
{
    void Sample();
}

[ServiceConfiguration(ServiceType = typeof(IService))]
public class TransientService : IService
{
    public void Sample()
    {
        throw new NotImplementedException();
    }
}

[ServiceConfiguration(
    ServiceType = typeof(IService),
    Lifecycle = ServiceLifetime.Singleton)]
public class SingletonService : IService
{
    public void Sample()
    {
        throw new NotImplementedException();
    }
}

Explicit registration of services

The following code shows examples of registering IService and its implementation Service using the IServiceCollection abstraction. Normally, service registrations are done in the Startup class or in an extension method like AddCms. The service registration abstraction is also available in initialization modules which implement the IConfigurableModule interface. There are convenient extension methods in namespaces Microsoft.Extensions.DependencyInjection, Microsoft.Extensions.DependencyInjection.Extensions and EPiServer.ServiceLocation. Inline comments describe the examples in more detail:

[InitializableModule]
public class ModuleWithServices : IConfigurableModule
{
    public void ConfigureContainer(ServiceConfigurationContext context)
    {
        // Register IService1 with implementation Service1, 
        // create new instance every time 
        context.Services.AddTransient<IService, Service>();

        // Register IService1 with implementation Service1, 
        // re-use a single instance 
        context.Services.AddSingleton<IService, Service>();

        // Register IService1 with custom factory 
        context.Services.AddTransient<IService>((locator) => new Service());

        // Register IService1 to be cached per scope, 
        // e.g. HTTP request 
        context.Services.AddScoped<IService, Service>();
    }

    public void Initialize(InitializationEngine context) { }
    public void Uninitialize(InitializationEngine context) { }
}

ServiceLocator

You should use dependency injection through constructors or use the DI container from a context like HttpContext.RequestServices. You can also use a static property ServiceLocator.Current to access the DI container in the rare places where there is no other way to get dependencies. If you use ServiceLocator.Current then if you use custom scopes, you should create the scopes using extension method CreateServiceLocatorScope instead of the extension method CreateScope within .NET Core. This gets the static accessor ServiceLocator.Current to be aware of the custom-created scope.

Intercept existing services

Sometimes, it is useful to intercept service calls, such as debugging or adding logging. By using the extension method Intercept<T> on IServiceCollection, you can replace existing services with another implementation. The provided factory method will have access to the default instance of the service.

If several implementations are registered for a service, registrations are intercepted. The interceptor service has the same scope as the intercepted service was registered with.

This example shows an interceptor registration of the ISynchronizedObjectInstanceCache where the interceptor logs remote removals.

using EPiServer.Framework;
using EPiServer.Framework.Cache;
using EPiServer.Framework.Initialization;
using EPiServer.Logging;
using EPiServer.ServiceLocation;
using System;

namespace EPiServerSamples
{
    [ModuleDependency(typeof(EPiServer.Web.InitializationModule))]
    public class LoggingInitializer : IConfigurableModule
    {
        public void ConfigureContainer(ServiceConfigurationContext context)
        {
            context.Services.Intercept<ISynchronizedObjectInstanceCache>((locator, defaultCache) =>
                new LoggingSynchronizedCache(defaultCache));
        }

        public void Initialize(InitializationEngine context) { }

        public void Uninitialize(InitializationEngine context) { }
    }

    public class LoggingSynchronizedCache : ISynchronizedObjectInstanceCache
    {
        private readonly ISynchronizedObjectInstanceCache _defaultCache;
        private readonly ILogger _log = LogManager.GetLogger(typeof(LoggingSynchronizedCache));

        public LoggingSynchronizedCache(ISynchronizedObjectInstanceCache defaultCache)
        {
            _defaultCache = defaultCache;
        }

        public void RemoveRemote(string key)
        {
            if (_log.IsDebugEnabled())
            {
                _log.Debug($"Remote removal called at '{DateTime.Now}' with key '{key}'");
            }

            _defaultCache.RemoveRemote(key);
        }

        public IObjectInstanceCache ObjectInstanceCache => _defaultCache.ObjectInstanceCache;

        public FailureRecoveryAction SynchronizationFailedStrategy
        {
            get
            {
                return _defaultCache.SynchronizationFailedStrategy;
            }
            set
            {
                _defaultCache.SynchronizationFailedStrategy = value;
            }
        }

        public object Get(string key) => _defaultCache.Get(key);

        public void Insert(string key, object value, CacheEvictionPolicy evictionPolicy) =>
             _defaultCache.Insert(key, value, evictionPolicy);
      
        public void Remove(string key) => _defaultCache.Remove(key);
        
        public void RemoveLocal(string key) => _defaultCache.RemoveLocal(key);
    }
}

Dependency injection use case examples

Optimizely CMS leverages Dependency Injection (DI) to manage the lifecycle and dependencies of services. Starting from CMS 12, which is built on ASP.NET Core, Optimizely fully integrates with the ASP.NET Core DI framework.

The following sections show dependency injection patterns in Optimizely CMS:

Constructor injection

This is the most common and recommended pattern for DI in Optimizely CMS. You inject dependencies through the constructor of a class. The DI framework automatically provides the required services when the class is instantiated.

Best use case – When your service class has mandatory dependencies that are required to perform its operations.

public class MyService
{
    private readonly IContentLoader _contentLoader;

    public MyService(IContentLoader contentLoader)
    {
        _contentLoader = contentLoader;
    }

    public void SomeMethod()
    {
        var content = _contentLoader.Get<IContent>(contentLink);  
    }
}

Property injection

In property injection, dependencies are injected into properties of the class, rather than through the constructor. The DI framework sets the properties after the object is created.

Best use case – When a dependency is optional, or you want to delay the injection until after the object has been constructed.

public class MyService
{
    [Inject]
    public IContentLoader ContentLoader { get; set; }

    public void SomeMethod()
    {
        var content = ContentLoader.Get<IContent>(contentLink);
    }
}

Method injection

In method injection, dependencies are provided as parameters to a specific method. This pattern is not as common as constructor injection but can be used when dependencies are only needed for specific methods.

Best use case – When a dependency is only required for a single method, or you want to provide different dependencies for different method calls.

public class MyService
{
    public void SomeMethod(IContentLoader contentLoader)
    {
        var content = contentLoader.Get<IContent>(contentLink);
    }
}

Scoped injection

Optimizely CMS supports the typical ASP.NET Core service lifetimes: Transient, Scoped, and Singleton. The Scoped lifetime is particularly useful in Optimizely for services that should be instantiated once per request. This is especially useful when dealing with HTTP context or request-specific data. See .NET dependency injection in the Microsoft documentation.