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:
-
Settings
ha l'aspetto di un tipo di dati, ma ha un comportamento - Non è ovvio che
Settings
sia persistente - Potrebbe violare il principio del minimo stupore
- Quando l'interfaccia pubblica di
Settings
cambia,AutoPersistSettingsDecorator
deve 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 aBank
object, but it is actually talking to a set of nested decorator objects that extend the basic behavior of theBank
POJO.
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?