Come propagare la classe di impostazione nell'intero progetto

2

Ecco la mia configurazione:

  1. Backend del framework Entity
  2. Progetto WPF di grandi dimensioni con una finestra principale con 3-4 controlli utente, ognuno dei quali ha 3-4 controlli utente su di esso (e così via, in alcuni casi)

Che cosa ho attualmente:

public class MySettings
{
   public string Property1 { get; set; }
   public string Property2 { get; set; }
   public string Property3 { get; set; }
   public string Property4 { get; set; }
}

public class FileService
{
    public void HandleFile();
    public event EventHandler FileChanged;
}


public class UserControl1
{
    MySettings settings;
    FileService fileService;
}

public class UserControl2
{
    MySettings settings;
    FileService fileService;
}

Ci sono alcuni UserControls (o VM) che devono conoscere la classe delle impostazioni. Ecco un esempio di cosa succede:

  1. Carichi dell'applicazione. L'utente accede alla "Finestra delle impostazioni".
  2. Impostazioni modifiche utente.
  3. UserControl1 riceve una notifica di modifica delle impostazioni e aggiunge un nuovo controllo utente
  4. UserControl2 viene avvisato di una modifica delle impostazioni e rende visibile uno stackpanel
  5. ecc, ecc., ecc.

Il mio dilemma:

Come gestisco tutti i controlli utente e le finestre che hanno accesso a queste classi? Domande specifiche:

  1. Devo creare una classe di impostazioni principale in un ViewModel di livello superiore e propagare questa classe di impostazioni attraverso una serie di submodelmodelli?
  2. Devo creare una classe statica per gestire tutti questi elementi?
  3. Il FileService dovrebbe essere propagato anche attraverso ogni ViewModel? Esiste un modo più pulito di fare Servizi assicurandosi che ogni controllo / finestra stia utilizzando lo stesso?
posta oppassum 05.12.2018 - 18:10
fonte

1 risposta

0

Penso che ciò che è meglio dipende dal progetto che ti piace.

Il mio caso: ho una piccola app. Ci sono alcune impostazioni, nessun test. Soluzione: metodi di classe statici da chiedere e impostare. Esempio

public static boolean IShouldAskTheUserToOpenThePrivacyPolicy() {
        return !userHasReadThePrivacyPolicy;
}

usato successivamente come

if (Settings.IShouldAskTheUserToOpenThePrivacyPolicy()) askIfTheUserLikesToSeeThePrivacyPolicy()

Ho pensato a

  • Una classe statica come ho
  • A Singleton: scriverò sempre Settings.instance ()
  • Uso di diversi oggetti / interfacce di impostazioni per classi diverse: questi erano buoni se avessi dei test.

Dato che Java vorrebbe che io introducessi un'interfaccia per le proprie impostazioni di ogni classe, preferisco fare il modello anti di una classe di grassi qui, rendendo evidente il posto per il contributo futuro di altre persone. Se fosse Python, userò comunque la classe e avrò dei test.

Come faccio a propagare le modifiche: È possibile osservare le impostazioni. Gli oggetti possono essere collegati come Observer (Pattern).

Con il servizio file è di nuovo la tua scelta. Non so cosa vuoi fare e cosa affronti.

Lingua: Se rinominare le impostazioni su UserPreferences, è chiaro che nell'app c'è un solo utente. Tuttavia, in un'applicazione server, questa non deve essere una classe Singleton / statica. Con "FileService" è di pari pensiero. "FileService" non rivela nulla su ciò che fa o su cosa ha bisogno di rispondere in atto. Quindi, non posso dirtelo. Se rispondi a cosa è il FileService per chi? Quindi, probabilmente non avrai bisogno di chiedermelo.

    
risposta data 06.12.2018 - 01:15
fonte

Leggi altre domande sui tag