Dato il modello del modello di presentazione, la vista, il modello di presentazione o il modello sono responsabili dell'aggiunta di viste secondarie a una vista esistente in fase di runtime?

Question

Dato il modello del modello di presentazione, la vista, il modello di presentazione o il modello sono responsabili dell'aggiunta di viste secondarie a una vista esistente in fase di runtime?

#1 da (1 voti)
#2 da (0 voti)

6

Sto costruendo un'applicazione basata su Flex 4 usando il modello di progettazione del modello di presentazione. Questa applicazione avrà diversi componenti diversi come mostrato nell'immagine qui sotto.

MainVieweDashboardViewsarannosemprevisibilieciascunodiessiavràmodelliemodellidipresentazionecorrispondenti,senecessario.QuestevistesonofacilmentecreatedichiarandoilloroMXMLnellarootdell'applicazione.

<s:HGroupwidth="100%" height="100%">
    <MainView width="75% height="100%"/>
    <DashboardView width="25%" height="100%"/>
</s:HGroup>

Ci saranno anche molte viste WidgetViewN che possono essere aggiunte a DashboardView dall'utente in fase di runtime attraverso un semplice elenco a discesa. Questo dovrà essere realizzato tramite ActionScript.

L'elenco a discesa dovrebbe sempre mostrare quale WidgetViewN è già stato aggiunto a DashboardView. Pertanto è necessario memorizzare alcuni stati sui quali è stato creato WidgetViewN. Poiché l'elenco di WidgetViewN disponibile e quelli aggiunti a DashboardView devono essere accessibili anche da altri componenti del sistema, penso che questo debba essere archiviato in un oggetto Model.

La mia comprensione del modello di progettazione del modello di presentazione è che la vista è molto snella. Contiene la logica più vicina a zero come è pratico. La vista comunica / si collega al modello di presentazione che contiene tutta la logica di visualizzazione necessaria. Il modello di presentazione è effettivamente una rappresentazione astratta della vista che supporta l'accoppiamento basso e facilita la testabilità. Il modello di presentazione può avere uno o più modelli iniettati per visualizzare le informazioni necessarie. I modelli stessi non contengono alcuna logica di visualizzazione.

Quindi ho alcune domande su questo progetto.

Chi dovrebbe essere responsabile per la creazione dei componenti WidgetViewN e l'aggiunta di questi a DashboardView? È questa la responsabilità di DashboardView, DashboardPresentationModel, DashboardModel o qualcos'altro interamente? Sembra che DashboardPresentationModel sia responsabile della creazione / aggiunta / rimozione di qualsiasi visualizzazione secondaria dalla sua visualizzazione, ma come si fa a farlo senza passare in DashboardView a DashboardPresentationModel?
L'elenco dei componenti WidgetViewN visibili e visibili deve essere accessibile anche ad alcuni altri componenti. Va bene se un riferimento a un WidgetViewN è memorizzato / referenziato in un modello?
Esistono buoni esempi del modello del modello di presentazione online in Flex che includono anche la creazione di viste secondarie in fase di runtime?

design-patterns mvvm flex presentation-model

posta Ryan Taylor 30.05.2012 - 15:15

fonte

2 risposte

Leggi altre domande sui tag design-patterns mvvm flex presentation-model

Esiste un modo per implementare un metodo di attraversamento veloce degli alberi che supporti il versioning datato? Utilizzo di oggetti / dati con versione per gestire la compatibilità della versione del programma?

score 1 · Answer 1

MVP è in qualche modo aperto all'interpretazione. Ho scritto un'app Flex 3 su larga scala con MVP, quindi darò il mio input sulla base dell'esperienza.

Dal punto di vista del relatore, è responsabilità della vista aggiungere sottoview (poiché le viste sono interfacciate - pensa la sostituzione dell'app della console). Nel presentatore non dovrebbe esistere alcuna vista specifica (ad esempio, dovresti essere in grado di testare l'unità con una vista simulata).

Hai ragione, la vista principale non dovrebbe fare neanche questo.

Il relatore per quella vista assegnerebbe un WidgetPresenterCatalog (popolato altrove nell'applicazione in base alla business logic) che la vista può scegliere. La vista delegherebbe tutta la presentazione, selezione e interazione del widget al componente DashboardView. Quel componente seleziona dal catalogo e li visualizza.

Problema n. 2: come visualizzarli! Nello stesso modo in cui connetti un presentatore e una vista. Hai una classe che sa come accoppiare un relatore e visualizzare e restituire la vista per la presentazione. Ancora una volta, il relatore passerebbe questo al MainView e MainView lo fornirebbe a DashboardView.

Ora il tuo MainView e Presenter dovrebbero essere ultraleggeri e i widget hanno una superficie minima su di essi.

score 0 · Answer 2

Per la spiegazione di Martin Fowler del modello di presentazione ( link ), credo che le risposte siano le seguenti:

FWIW, non sono un esperto nel modello del modello di presentazione.

1) Sarebbe nel DashboardPresentationModel poiché contiene la logica di presentazione per il tuo programma. Tale logica determinerebbe quindi se il widget è consentito o meno, oltre a creare l'istanza successiva.

2) Se comprendo correttamente il layout, ritengo che la risposta sia no. PresentationModel deve contenere tali informazioni e, se necessario, fornire metodi per accedere a tali informazioni.

3) Spiacente, non lo so.