Capire come vengono caricate dal database le impostazioni di Nop Commerce

Question

Sto lavorando con Nop Commerce e mi chiedo se qualcuno possa aiutarmi con la mia confusione.

Ho eseguito il debug del codice molte volte cercando di scoprire come vengono caricate le impostazioni all'avvio dell'applicazione web. Io proprio non capisco!

Tutte le classi di impostazioni implementano l'interfaccia ISettings. Prendiamo ad esempio le impostazioni del cliente. Ho scoperto che è rappresentato dalla classe CustomerSettings. Nel database c'è un Setting table. I dati per le impostazioni dei clienti sembra somethng come questo:

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

Come e dove sono ciascuna di queste impostazioni mappati dal customersettings alla classe CustomerSettings e una proprietà come usernamesenabled mappato alla proprietà UsernamesEnabled nella classe CustomerSettings? E perché è stato implementato in questo modo?

So che ha qualcosa a che fare con il seguente codice nella classe DependencyRegistrar:

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

Se qualcuno mi può puntare nella giusta direzione, allora sarebbe apprezzato.

Answer 1

Spero di non essere in ritardo.

ci sono solo alcuni punti importanti da guardare per capire come si crea quella struttura:

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

L'SettingsService fornisce solo la funzionalità per archiviare e recuperare le impostazioni dai repository, e implementa alcune funzionalità di caching.

Il ConfigurationProvider esegue la magia effettiva.

Vediamo il metodo 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 }; 

Utilizzando riflessione, classe * Impostazioni (per esempio, CustomerSettings), sono controllati e le loro proprietà utilizzata per caricare le impostazioni corrispondenti dal servizio.

Poi si converte di nuovo il valore memorizzato come stringa (è possibile controllare il NopCustomTypeConverter per vedere come la serializzazione accade) e assegnarli tornare all'impostazione Entity:

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

L'altro metodo, SaveSettings (impostazioni TSettings) sortisce l'effetto contrario, prende un'entità Ambito e si rompe, generando coppie di chiavi a valore sotto forma di ClassName + Propertyvalues)

'stato implementato così perché dispiega concetti da IoC, segregation of interfaces, n-tier e altri modelli per garantire la manutenibilità (componentizzazione basata su API, testabilità ecc.).