This feature seems to be overlooked, so I hope this blog post will draw more attention to this feature, and make it’s use more widespread.

In Sitecore, it is easy to map configuration settings to a C# class, whilst maintaining a structure that adheres to the helix principles, see the config below.

Then the mapped C# class can registered with IServiceCollection, so it can be injected into any class using dependency injection.

<?xml version="1.0"?> <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:environment="http://www.sitecore.net/xmlconfig/environment"> <sitecore environment:require="Local"> <feature> <salesforce> <clientSettings type="Example.Feature.Salesforce.Infrastructure.SalesforceClientSettings, FKCC.Feature.Salesforce" singleInstance="true"> <Username>example@blog.example.com</Username> <Password>xxxxxxx</Password> <Token>yyyyyyy</Token> <CacheExpiry>60</CacheExpiry> <OrganisationId>1111111</OrganisationId> </clientSettings> </salesforce> </feature> </sitecore> </configuration>

Previously settings used to be a long flat list of settings, which if we were lucky were grouped use prefixes in the name attribute to indicate which feature they were used by.

<setting name="Feature.Salesforce.Authentication.Username" value="xxxx@example.com" /> <setting name="Feature.Salesforce.Authentication.Password" value="BestPasswordInTheWorld" /> <setting name="Feature.Salesforce.Authentication.SfToken" value="Its a SF token" /> <setting name="Feature.Salesforce.Authentication.CacheExpiry" value="60" />

Solution

It is now very simple to map structured configuration to a type safe C# class, and it involves 4 simple steps.

Step 1 – Define C# Class

Define the C# class that stores the data defined by the settings in the config file, for this example, we will define some authentication settings for a sales force client.

namespace Example.Feature.Salesforce.Infrastructure { public class SalesforceClientSettings { public string Password { get; protected set; } public string Username { get; protected set; } public string Token { get; protected set; } public int CacheExpiry { get; protected set; } public string OrganisationId { get; set; } } }

Step 2 – Define the settings

It is not required, but I would recommend following the Helix principles when defining the settings structure i.e.

[Layer]/[Feature Name]/[Settings Name]

The type attribute defines which class (i.e. the one defined in step 1) to map the settings element to.

<?xml version="1.0"?> <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:environment="http://www.sitecore.net/xmlconfig/environment"> <sitecore environment:require="Local"> <feature> <salesforce> <clientSettings type="Example.Feature.Salesforce.Infrastructure.SalesforceClientSettings, FKCC.Feature.Salesforce" singleInstance="true"> <Username>example@blog.example.com</Username> <Password>xxxxxxx</Password> <Token>zzzzzz</Token> <CacheExpiry>60</CacheExpiry> <OrganisationId>1111111</OrganisationId> </clientSettings> </salesforce> </feature> </sitecore> </configuration>

Step 3 – Map the configuration to the C# class

Sitecore makes this so easy, using Factory.CreateObject method, which loads the configuration and maps it to the C# class.

(SalesforceClientSettings) Factory.CreateObject("feature/salesforce/clientSettings", true)

Note: Factory.CreateObject expects that configuration path, is relative to the sitecore configuration, not the complete path.

Step 4 Setup dependency injection.

Register the created class with the IServiceCollection, so we can access the class, where necessary using constructor injection.

namespace Example.Feature.Salesforce.Infrastructure { public class ServiceConfigurator : IServicesConfigurator { public void Configure(IServiceCollection serviceCollection) { serviceCollection.AddSingleton(provider => (SalesforceClientSettings) Factory.CreateObject("feature/salesforce/clientSettings", true)); } } }

I hope this blog posts, helps you to structure your settings in a more maintainable and coherent structure, Alan