Fa Passive View infrange la legge di Demetra?

Question

Sto cercando di capire come utilizzare Passive View correttamente. Mi sembra che ogni esempi che guardano su Passive View infrange la legge di Demetra:

//In the presenter code
myview.mytextfield.text = "whatever";

Così che cosa è una migliore attuazione della Passive View?

Answer 1

In primo luogo, la legge di Demetra, come la maggior parte le regole di programmazione, è più di un principio o linea guida e ci sono occasioni in cui il principio non si applica. Detto questo, la Legge di Demetra in realtà non si applica a Passive View perché la ragione per la legge non è un problema in questo caso.

La Legge di Demetra sta cercando di impedire la dipendenza concatenamento come ad esempio:

objectA.objectB.objectC.DoSomething();

Ovviamente se le modifiche di implementazione di ObjectB di utilizzare objectD invece poi si romperà la dipendenza Objecta e causare un errore di compilazione. Se preso ad un estremo si finisce per fare un intervento chirurgico fucile qualsiasi momento la catena è disturbato da un cambiamento di implementazione.

Nel caso di Passive View

• Il presentatore dipende da un'interfaccia in modo implementazione della vista può cambiare fino a quando l'interfaccia rimane la stessa.
• Il punto di vista di solito espone le proprietà come tipi di dati generalizzate quali tipi di sistemi e collezioni. Ciò consente di apportare modifiche alla UI senza influenzare il presentatore.
• Per il presentatore della vista appare come nient'altro che una struttura di dati, un luogo per recuperare e scaricare i dati. Dal momento che la vista è piuttosto semplice, il presentatore non dovrebbe nemmeno essere in grado di fare la dipendenza concatenamento.

Così l'esempio che ha dato normalmente essere implementato:

//from presenter
view.MeaningfulName = "data";

Mentre la vista sarebbe qualcosa di simile:

//from view
public string MeaninfulName
{
    get
    {
        return someControl.text;
    }
    set
    {
        someControl.text = value;
    }

Spero che questo chiarisce le cose un po '.

Answer 2

Una migliore applicazione sarebbe di avere un'API tra il presentatore e la vista. Il presentatore spingerebbe i dati al suo Vista attraverso un unico metodo (definito nella interfaccia della vista). La vista sarebbe gestire il nuovo ingresso secondo una logica interna.

Pertanto, il presentatore non deve sapere nulla circa la vista e la Legge di Demetra è sicuro.

Answer 3

Va bene, beh, sì, che ha rompere la Legge di Demetra, che dice in sostanza che l'interfaccia a un oggetto non dovrebbe rivelare l'attuazione dell'oggetto. Ma poi, il secondo dà un sacco helluva di suggerimenti per l'implementazione troppo.

Credo che sia tempo di chiedere se avete la giusta interfaccia in generale. Ciò che sono questi campi di testo? Chi li sta mettendo in vista? Non dovrebbe essere la vista chiedendo il modello per i dati, invece di viceversa?

Forse è necessario il pattern Observer -. Il modello mantiene un elenco delle parti interessate e li avvisa quando i suoi cambiamenti di stato interni

---

Ah, che Passive View. Non aveva guardato che in un lungo tempo. Fondamentalmente, vedo due parti: una di queste è che facendo il controller (non il modello) guidare tutti gli aggiornamenti, per la (presumo) l'efficienza egli espone i metodi di campo specifiche per aggiornare i campi. Ciò non violare la legge di Demetra, che è, dopo tutto, solo una "legge" in un certo senso metaforico, come la legge di Murphy. Di solito è una buona idea, però. In questo caso, mi piacerebbe rifare la vista e usarlo come una facciata per avvolgere gli aggiornamenti al singolo campo.

Non è necessario il pattern Observer, però, perché ora hai il controller facendo tutti gli aggiornamenti. Si aggiunge una certa complessità e l'errore predisposizione al codice complesso, perché ora si hve di scrivere il controller per effettuare gli aggiornamenti in parallelo.