Come si naviga tra le viste in MVP usando C# WinForms?

Question

Come ho capito, quando usiamo MVP spostiamo tutta la logica di presentazione al Presenter. Ma non vogliamo che il Presentatore conosca l'implementazione della vista, quindi come possiamo navigare verso un'altra schermata nell'applicazione? Come gestisci il flusso delle applicazioni sulla tua applicazione reale?

Answer 1

È un metodo per la visualizzazione. Quindi, ad esempio, avresti un metodo astratto, come ShowCustomerForm(), e l'implementazione per WinForms sarebbe CustomerForm.Show (o qualunque cosa sia in WinForms) e in WebForms sarebbe Response.Redirict (CustomerForm.aspx).

Answer 2

Utilizzando alcune interfaccia navigatore, ad esempio:

interface INavigator 
{ 
    void MoveTo (string screenName); 
    void MoveTo (string screenName, NavigationParameters parameters); 
} 

Ogni presentatore avrebbe quindi un esempio di questo navigatore passata nel costruttore. In questo modo la navigazione viene disaccoppiata sia dal presentatore che dalle singole visualizzazioni.

È possibile avere la mappatura tra i nomi delle schermate e le classi di Form effettive definite in una configurazione.

Answer 3

Suppongo che intendi un'altra schermata con la propria coppia MVP?

stavo pensando a quel caso stamattina, la mia soluzione sarà probabilmente che c'è un coordinatore che conosce il Presenter e la coppia MVP che deve essere aperta. Quella apre la nuova vista relatore + e, al termine, chiama facoltativamente un metodo sul primo presentatore con i risultati.

In questo modo, il primo MVP non deve sapere nulla sul nuovo schermo, ma solo un evento. La logica per aprire la seconda finestra e comunicare indietro è interamente contenuta nel coordinatore.

Answer 4

Facciamo ciò utilizzando ciò che Lennaert chiama un coordinatore (lo chiamiamo un controllo del flusso di lavoro). Vengo dallo sviluppo web Java e l'idea era una forma di ApplicactionController. Ho incontrato alcuni problemi con questo, workflowcontroller esegue un comando. Ogni comando rappresenta un flusso di lavoro o una serie di passaggi correlati (quindi il nome workflowcontroller). Il controllore di flusso gestisce la navigazione tra i comandi e un controllore di flusso ha un navigatore che naviga tra i gradini. Ogni fase ha un evento finale (a cui il relatore viene collegato) e il metodo NextStep che usiamo per andare al passaggio successivo. Il nostro worflowcontroller è strettamente collegato al menu in modo da poter navigare tra diversi flussi di lavoro. I passaggi stabiliscono il collegamento tra visualizzazione e presentatori. Non abbiamo alcuna configurazione e abbiamo cablato la logica che stabilisce il prossimo passo da eseguire in un metodo chiamato NextStep. È in produzione, ma non ne sono molto soddisfatto. Troppi dettagli per entrare qui. Ho pensato di passare a qualcosa che è più guidato dagli eventi. Usiamo un bus di messaggi per fare tutte le altre nostre comunicazioni e mi piacerebbe passare a usare questo per navigare tra le schermate. Non so se sarebbe utile o meno. i nostri schermi per la maggior parte sono costituiti da flussi di lavoro sequenziali.