Quando il modello di progettazione del modello di presentazione dovrebbe includere uno o più controllori?

4

Ho svolto ricerche sull'uso del modello di progettazione del modello di presentazione per un'applicazione che mi sto preparando a costruire. La tecnologia specifica che userò è Flex anche se dubito che sia importante per questa domanda.

In generale, la maggior parte degli esempi del modello di presentazione che ho eseguito sono abbastanza coerenti nell'implementazione di base. Più o meno seguono descrizione del modello di presentazione di Martin Fowler a un T quando si tratta dei tre concetti di base: vista, modello, Modello di presentazione.

Penso di capirlo.

Tuttavia, ho visto alcuni altri esempi che estendono ulteriormente questo includendo oggetti controller, eventi e servizi oltre ai tre costrutti di base che ho elencato sopra. Gli esempi che ho visto sono (si noti che entrambi utilizzano Swiz per DI e gestione degli eventi):

Capisco il ragionamento per un livello di servizio. Potresti desiderare / dover recuperare i tuoi dati da un'interfaccia SOAP un giorno, un'interfaccia REST il successivo e un SharedObject il terzo giorno. L'interfaccia del livello di servizio semplifica lo scambio della logica di recupero e persistenza.

Tuttavia, non sono sicuro di aver capito perché l'aggiunta del controller è un vantaggio?

Negli esempi collegati sopra, alcune logiche all'interno del modello di presentazione vengono inviate e gestite all'interno del modello di presentazione stesso mentre altre logiche vengono inviate e indirizzate all'interno di un controller.

La mia ipotesi è che la logica che è specifica della vista viene catturata all'interno del modello di presentazione. Questo supporta l'idea che il modello di presentazione sia semplicemente una rappresentazione astratta della vista.

Inoltre, sospetto che i controller siano utilizzati per acquisire la logica aziendale comune e gli eventi che non sono specifici della vista e non vengono eseguiti dal livello di servizio (ad esempio, persistenza). Questo dovrebbe supportare il riutilizzo attraverso l'applicazione e contribuire a rendere l'applicazione più testabile.

  • Questa conclusione è giusta?
  • Ci sono altri vantaggi che mi mancano?
  • Quali sono gli svantaggi (oltre a più codice)?
  • Come fai a sapere quando la logica dovrebbe essere nel modello di presentazione e quando deve risiedere in un controller?
posta Ryan Taylor 05.10.2011 - 19:22
fonte

1 risposta

1

Il motivo di base per un controller è Separazione dei dubbi ... Ciò che descrivi è una combinazione di MVC e i modelli MVVM, che è davvero il mio approccio di scelta.

Fondamentalmente hai il tuo solito Model View Controller, ma aggiungi ViewModel. Questo ti aiuta a creare un codice più riutilizzabile e una vera separazione tra il tuo Data Layer, la tua Business Logic e la tua presentazione.

Gli svantaggi? bene, come hai detto più codice. A parte questo, non che mi faccia pensare due volte.

Dove dovrebbe essere la logica? Business Logic nel controller, Logica di presentazione nel ViewModel e nella Vista.

    
risposta data 05.10.2011 - 20:32
fonte

Leggi altre domande sui tag