Passaggio di oggetti MVVM ad altre classi [chiuso]

2

Quindi sto usando C # WPF e leghiamo a una vista modello per visualizzare gli stati. I dati che devono essere visualizzati sono distribuiti su un paio di classi diverse. Ad esempio, ho una classe che legge i valori IO digitali che devono essere visualizzati sull'interfaccia principale come luci rosse o verdi.

È meglio passare semplicemente l'oggetto Model alle classi per aggiornare direttamente le proprietà? Sembra più facile a breve termine ma ha un odore strano.

Modifica

Penso che una parola migliore per ciò che sto chiedendo sia l'incapsulamento. L'incapsulamento sembra essere un concetto importante in OOP.

Nel caso 1 il modello è "incapsulato" nella classe Main. Altri oggetti non interagiscono direttamente con il modello. vengono utilizzati metodi delegati. Questo sembra prolisso e un po 'disordinato, ma questa è la soluzione che sto cercando di mantenere incapsulato i dati.

Nel caso 2 il modello viene passato a un oggetto secondario come argomento nel costruttore, che agisce sul modello contemporaneamente all'istanza originale. Sembra infrangere la regola di incapsulamento e potrebbe essere fonte di confusione nel numero di posizioni al quale il modello può accedere. Questo sarà particolarmente vero dove varie classi hanno dati che devono essere visualizzati.

Questo potrebbe essere interamente basato sull'opinione pubblica. Vedo vantaggi e insidie di entrambi gli approcci. Il caso 2 non si presta a essere riutilizzato. Mentre il caso 1 potrebbe essere implementato altrove.

In pratica si preferisce l'uno rispetto all'altro? Quanto è importante l'incapsulamento? Devo mantenerlo a scapito della leggibilità?

MSDN Implementazione del pattern MVVM

Well-designed view, view model, and model classes will not only encapsulate the correct type of code and behavior; they will also be designed so that they can easily interact with each other via data binding, commands, and data validation interfaces.

END EDIT

La soluzione su cui sto lavorando utilizza i delegati. Ad esempio:

Caso 1

public delegate void PrependLog(string log);

public class MyDemoClass
{

   private void DoStuff(string str)
   {
     //Do stuff
     OnPrependLog("Did stuff");
   } 
   public PrependLog PrepLog
   public virtual void OnPrependLog(string str)
   {
      if(PrepLog != null)
         PrepLog(str);
   }

}

Quindi dal principale:

public MainWindow()
{

   MyDemoClass objDem = new MyDemoClass;
  //Assign delegate
   objDem.PrepLog = (val) => {Model.LogText += val;}


}

Ma dal punto di vista della leggibilità, sembra che sarebbe più semplice passare il MyDemoClass del modello e aggiornare direttamente il testo del registro.

Case2

public class MyDemoClass
{
  MyModel Model;

  public MyDemoClass(MyModel model)
  {
    Model = model;

  }

  private void DoStuff(string str)
   {
     //Do stuff
     Model.LogText += "Did Stuff";
   } 

}
    
posta Felix Castor 08.12.2015 - 23:12
fonte

1 risposta

2

Spero che tu capisca che non esiste una risposta obiettiva alla tua domanda, e in quanto tale è passibile di essere chiusa come fondamentalmente basata sull'opinione pubblica. Ma curiosamente, il voto ravvicinato finora è per "non chiaro cosa stai chiedendo", il che significa semplicemente che qualcuno non ha capito cosa stai chiedendo. Quindi, ecco un parere.

Supponendo che queste "classi" delle tue appartengano concettualmente al modello, (altrimenti, nulla ha senso e hai altri problemi seri,) è, a mio parere, perfettamente a posto passare la modella a loro, in modo che possono usare i servizi offerti dal modello.

Ultimamente ho usato con successo questo schema che ho creato, che chiamo Disegno orientato al soggetto e Programmazione orientata al soggetto . È ispirato da Domain Driven Design . In pratica dice che ogni singolo oggetto che appartiene a un dominio (e i modelli sono praticamente sempre domini) è posseduto dal dominio, quindi è un soggetto del dominio. (Pensa al dominio come a un regno, dove gli abitanti sono sudditi.)

Si applicano varie regole, ad esempio nessuno è autorizzato a creare un'istanza di un soggetto tranne il dominio stesso, quindi i domini fungono da fabbriche per i loro soggetti, ma le regole che potresti trovare di interesse per la tua situazione particolare sono:

  • Ogni singolo soggetto riceve come primo parametro costruttore un riferimento al proprio dominio. Concettualmente, questo è legato al modo in cui ogni singolo metodo di istanza di una classe riceve come primo parametro un puntatore (nascosto) this . I metodi di istanza hanno bisogno del puntatore this per accedere ai membri dell'oggetto, i soggetti hanno bisogno del puntatore domain per accedere ai servizi del dominio.

  • Il dominio mette a disposizione vari servizi per i suoi soggetti e, poiché ogni soggetto ha un riferimento al proprio dominio, ottiene qualsiasi servizio di cui ha bisogno dal dominio e lo utilizza. In questo modo, l'inversione del controllo (iniezione di dipendenza) è necessaria solo a livello di dominio, non a livello di singolo soggetto. E naturalmente i domini possono essere soggetti ad altri domini, quindi l'iniezione di dipendenza può essere raggiunta molto facilmente passando servizi a costruttori di domini, senza la necessità di quadri di iniezione di dipendenza magica come Spring .

risposta data 09.12.2015 - 09:27
fonte

Leggi altre domande sui tag