Comunicazione inter-controllore in MVC/MVP

Question

Che cosa è un buon metodo per la comunicazione inter-controllore senza accoppiamento in MVC/MVP?

Ad esempio, in un preventivo, l'utente deve creare e aggiungere un nuovo contatto o aggiungerne uno esistente.

Hanno scelto di creare un nuovo contatto. Al termine, il contatto viene aggiunto all'offerta e l'interfaccia utente restituisce all'utente tale quota. Se colpiscono annullare, sono restituiti alla citazione.

Voglio riutilizzare Contatto altrove, quindi non dovrebbe sapere nulla su Quote. Ad esempio, se creo un contatto dall'elenco dei contatti, dovrebbe tornare lì al termine.

Qui ci sono alcune opzioni che ho pensato:

• azione ContactsController chiama ApplicationController.getNextStep (questo) e l'ApplicationController Figure fuori il passo successivo per conto del ContactsController

• ContactsController solleva l'evento "actioncomplete" o simile, e ApplicationController è in ascolto per questo evento e chiama il passaggio successivo corretto

• QuoteController passa in "testimone" a ContactsController con il passo successivo, che ContactsController chiama quando fatto

• ContattiController solleva l'evento "actioncompleto" o simile, e QuotesController è in ascolto per questo evento e chiama il passaggio successivo corretto.

Hai esperienza con questi? Altre idee? Quale causerà il minor numero di mal di testa in una grande app?

Grazie!

Answer 1

Indovina che risponderò alla mia domanda. Spero di avere quella dolce, dolce generosità.

Pensa a questo dal punto di vista dell'invio del tuo collaboratore a un cliente. Sa come fare il suo lavoro, ma non sa cosa fare quando ha finito. Vuoi che sia flessibile su ciò che fa dopo.

A volte il suo capo lo manda fuori. A volte il CEO lo fa (potrebbe non sapere dove mandarlo dopo). A volte il cliente lo chiama con un'emergenza (sicuramente non sa dove mandarlo dopo). A volte prende semplicemente una nuova attività dalla lavagna.

Si potrebbe fare una delle diverse cose:

• si potrebbe dirgli di chiamare l'ufficio di testa quando ha fatto, e la sede sarà capirlo per lui. non ha bisogno di sapere di altre persone, solo il numero di telefono della sede centrale.

• potresti dirgli cosa fare quando ha finito, prima che lui se ne vada. se è andato via per un po ', il suo prossimo compito potrebbe essere cambiato nel frattempo.

• potresti dirgli di postare su facebook quando ha finito, la sede centrale lo cercherà e gli dirà cosa fare. la sede centrale avrebbe bisogno di guardare molti post su Facebook da tutti i loro consulenti.

• Si potrebbe dire al suo supervisore di rispondere alla chiamata quando ha finito, ma poi il suo supervisore deve essere in ufficio, e forse cambierà i supervisori.

Personalmente, passerei in una funzione di richiamata. Se tale callback è nullo, il chiamato deve chiedere all'applicazione cosa fare. Questo ti dà una certa flessibilità, mentre consente anche a un processo genitore di gestire le cose, e non fare affidamento su una grande funzione nell'app.

Questo equivarrebbe a fornire al consulente il numero del prossimo cliente da chiamare, quando ha finito. Se non riceve un numero, chiama la sede centrale.

È possibile utilizzare anche un evento e non è una cattiva idea. L'unico problema potrebbe essere se più oggetti sono in ascolto per questo evento, potrebbe accadere qualcosa di spiacevole.

Answer 2

È possibile implementare una qualche forma di stack di navigazione, in cui vengono inizialmente inseriti i controller Quote o Contatti, quindi vengono inseriti il ​​controller Contatto quando richiesto. Quando il controller Contatto è terminato, si spegne da solo e raggiunge il prossimo per sapere dove andare. In questo modo è completamente disaccoppiato e può essere riutilizzato ovunque, e può essere nidificato in profondità.

Answer 3

Se ho compreso correttamente la tua domanda, hai un'azione ben incapsulata da un controller e desideri assicurarti che il suo comportamento post-esecuzione possa essere definito nel modo più dinamico possibile.

L'idea di una funzione di callback è molto buona, ma farei un ulteriore passo avanti e renderlo un Func <>, che consente di utilizzare le chiusure. Espanderò la tua metafora del consulente: invece di passare un numero di telefono al tuo rappresentante, dovresti invece riconnettermi in ufficio e ricevere istruzioni da lì. La bellezza dell'utilizzo delle chiusure è che è possibile accedere al contesto chiamante direttamente dal codice, altrimenti fuori dall'ambito di applicazione; in altre parole, la chiusura può accedere a tutte le delle variabili e delle funzioni nel controller host.

Quando il venditore è fatto con il suo compito, ha semplicemente apre la sua valigetta (Func <>) e raggiunge nella sua scrivania in ufficio per vedere se qualcuno ha messo un elemento To-Do nel cassetto dell'ufficio.

Jon Skeet (anche su StackOverflow) ha una grande risorsa qui: http://csharpindepth.com/articles/chapter5/closures.aspx