In un'applicazione MVVM (Xamarin.Forms, FWIW) ho un viewmodel che memorizza le impostazioni in modo esplicito
public class SettingsPageViewMode : INavigatedAware
{
ISettingsRepository settingsRepository; // injected
public void OnNavigatedTo(NavigationParameters navigationParameters)
{
var settings = settingsRepository.LoadSettings();
this.SomeBoolSetting = settings.SomeBoolSetting;
}
public bool SomeBoolSetting
{
get => someBoolSetting;
set
{
if(someBoolSetting == value)
{
return;
}
someBoolSetting = value;
OnPropertyChanged("SomeBoolSetting");
UpdateSettings();
}
}
private void UpdateSettings()
{
var settings = settingsRepository.LoadSettings();
settings.SomeBoolSetting = SomeBoolSetting;
settingsRepository.SaveSettings(settings);
}
}
Sto pensando se è una buona idea che le impostazioni si memorizzino automaticamente tramite un decoratore che viene istanziato quando ISettingsRepository restituisce un oggetto Settings
internal class AutoPersistSettingsDecorator : Settings
{
Settings settings;
ISettingsRepository settingsRepository;
public AutoPersistSettingsDecorator(Settings settings, ISettingsRepository settingsRepository)
{
this.settings = settings;
this.settingsRepository = settingsRepository;
}
public override bool SomeBoolSetting
{
get => settings.SomeBoolSetting;
set
{
if(settings.SomeBoolSetting == value)
{
return;
}
settings.SomeBoolSetting = value;
settingsRepository.SaveSettings(settings);
}
}
}
Ciò semplificherebbe il modello di vista e renderebbe trasparente il salvataggio delle impostazioni
public class SettingsPageViewMode : INavigatedAware
{
ISettingsRepository settingsRepository; // injected
Settings settings;
public void OnNavigatedTo(NavigationParameters navigationParameters)
{
var settings = settingsRepository.LoadSettings();
this.SomeBoolSetting = settings.SomeBoolSetting;
}
public bool SomeBoolSetting
{
get => settings.SomeBoolSetting;
set
{
if(settings.SomeBoolSetting == value)
{
return;
}
settings.SomeBoolSetting = value;
OnPropertyChanged("SomeBoolSetting");
}
}
}
Possibili svantaggi:
-
Settingsha l'aspetto di un tipo di dati, ma ha un comportamento - Non è ovvio che
Settingssia persistente - Potrebbe violare il principio del minimo stupore
- Quando l'interfaccia pubblica di
Settingscambia,AutoPersistSettingsDecoratordeve cambiare, anche - Potrebbe essere soggetto a errori
Tuttavia, Clean Code propone ancora (più o meno) questo design (non ho un numero di pagina, dato che sto leggendo su un Kindle, ma è nella parte 11 (Systems), nelle sezioni su AOP, subito dopo la Figura 11-3)
The client believes it is invoking
getAccounts()on aBankobject, but it is actually talking to a set of nested decorator objects that extend the basic behavior of theBankPOJO.
Ho avuto qualcosa di fondamentalmente sbagliato? Dovrei creare la classe delle impostazioni più centrata sul caso d'uso? Come potrei ottenerlo, dal momento che fondamentalmente ho una visione molto simile ai dati di una classe di impostazioni. Questo approccio è del tutto appropriato quando si tratta di impostazioni?