Comprender cómo se cargan las configuraciones de Nop Commerce desde la base de datos

Question

Estoy trabajando con Nop Commerce y me pregunto si alguien puede ayudarme con mi confusión.

He depurado el código muchas veces tratando de averiguar cómo se cargan las configuraciones en el inicio de la aplicación web. ¡Simplemente no entiendo!

Todas las clases de configuración implementan la interfaz ISettings. Permite tomar las configuraciones del cliente, por ejemplo ... He descubierto que está representado por la clase CustomerSettings. En la base de datos hay un Setting table. Los datos de configuración del cliente se ve somethng así:

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

¿Cómo y dónde son cada uno de estos valores asignados de customersettings a la clase CustomerSettings y una propiedad como usernamesenabled asignada a la propiedad UsernamesEnabled en la clase CustomerSettings? ¿Y por qué se implementó de esta manera?

sé que tiene algo que ver con el código siguiente en la clase DependencyRegistrar:

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

Si alguien me puede apuntar en la dirección correcta, entonces sería apreciada.

Answer 1

Espero no llegar tarde.

hay sólo unos pocos puntos relevantes para mirar a entender cómo se crea esa estructura:

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

El SettingsService sólo proporciona funcionalidad para almacenar y recuperar la configuración de los repositorios, e implementa algunas funciones de almacenamiento en caché.

ConfigurationProvider hace la magia real.

Veamos el método BuildConfiguration:

 // 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 }; 

El uso de la reflexión, la clase * Ajustes (por ejemplo, CustomerSettings), han sido inspeccionados y sus propiedades que se utilizan para cargar los ajustes correspondientes del servicio.

Entonces se convierte de nuevo el valor almacenado como cadena (se puede comprobar la NopCustomTypeConverter para ver cómo se produce la serialización) y asignarlos a la entidad Marco:

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

El otro método, SaveSettings (Configuración de TSettings) hace exactamente lo contrario, toma una entidad Setting y la divide, generando pares clave-valor en la forma de ClassName + Propertyvalues)

Se implementó así porque despliega conceptos de IoC, segregation of interfaces, n-tier y otros patrones para garantizar el mantenimiento (componente basado en API, ecc de testabilidad).