Understanding how Nop Commerce settings are loaded from the database

Question

I work with Nop Commerce and wonder if anyone can help me with my confusion.

I debugged the code many times trying to figure out how the settings load when the web application starts. I just do not understand!

All configuration classes implement the ISettings interface. Take, for example, client settings. I found out that it is represented by the CustomerSettings class. There is a Setting table in the database. The data for user settings looks something like this:

 customersettings.usernamesenabled customersettings.checkusernameavailabilityenabled customersettings.allowuserstochangeusernames ... and so on... 

How and where does each of these parameters map to CustomerSettings with the CustomerSettings class and a usernamesenabled type property mapped to the usernamesenabled property in the CustomerSettings class? And why was this implemented in this way?

I know this has something to do with the following code in the DependencyRegistrar class:

 builder.RegisterGeneric(typeof(ConfigurationProvider<>)).As(typeof(IConfigurationProvider<>)); builder.RegisterSource(new SettingsSource()); 

If someone can point me in the right direction then this will be appreciated.

Answer 1

I hope I'm not late.

There are only a few relevant points to understand how this structure is created:

 -Nop.Services.Configuration.ConfigurationProvider class -Nop.Services.Configuration.ISettingsService interface -Nop.Services.Configuration.SettingsService class 

SettingsService provides only functions for saving and retrieving settings from repositories and implements some caching functions.

ConfigurationProvider does the actual magic.

Take a look at the BuildConfiguration method:

  // get properties we can write to var properties = from prop in typeof(TSettings).GetProperties() where prop.CanWrite && prop.CanRead let setting = _settingService.GetSettingByKey<string>(typeof(TSettings).Name + "." + prop.Name) where setting != null where CommonHelper.GetNopCustomTypeConverter(prop.PropertyType).CanConvertFrom(typeof(string)) where CommonHelper.GetNopCustomTypeConverter(prop.PropertyType).IsValid(setting) let value = CommonHelper.GetNopCustomTypeConverter(prop.PropertyType).ConvertFromInvariantString(setting) select new { prop, value }; 

Using reflection, * The settings class (for example, CustomerSettings) is checked and their properties are used to load the corresponding parameters from the service.

It then converts back the value stored as a string (you can check the NopCustomTypeConverter to see how serialization happens) and assign them back to the Entity setting:

properties.ToList().ForEach(p => p.prop.SetValue(Settings, p.value, null));

Another SaveSettings method (TSettings settings) does the exact opposite, takes a Setting object and breaks it, generating key and value pairs in the form of ClassName + Propertyvalues

It was implemented like this because it deploys concepts from IoC , separation of interfaces , n-level and other maintainability templates (based on API, ecc compliance check).