MVP - Il relatore dovrebbe usare Session?

Question

Sto usando il modello Model-View-Presenter per una pagina web. Il relatore dovrebbe essere a conoscenza della Sessione o solo l'opinione dovrebbe esserne consapevole?

Immagino che ciò a cui sto arrivando è che concetti come Sessione sono molto correlati all'architettura della vista, quindi dovrebbero essere limitati all'uso della vista? Altrimenti cosa succederebbe se volessi riutilizzare il presentatore su una pagina simile su un'architettura diversa (o non dovrei preoccuparmi a meno che non abbia intenzione di farlo)?

Answer 1

Sto facendo qualcosa del genere nella mia implementazione MVP Inietto un ICookieManager, ISessionManager, ICacheManager, IConfigurationManager, IRedirector nel mio presentatore che sono implementati da classi che racchiudono le funzionalità per questo.

Ciò consente a un presentatore in cui è possibile iniettare versioni derise di questi e non si hanno dipendenze dirette sul runtime asp.net nel proprio presentatore, in modo da semplificare i test.

Saluti

Answer 2

Potrebbe anche essere un modulo condiviso che funge da wrapper in qualsiasi sessione che si sta utilizzando. In questo modo sarebbe disponibile per tutti i tuoi controller e potresti semplicemente cambiare l'implementazione fisica della sessione.

Il relatore riempirebbe la vista di qualunque cosa il controller abbia recuperato dalla sessione.

Answer 3

Grazie per le risposte a tutti, quindi per riassumere ...

Stiamo dicendo che in realtà il Presentatore dovrebbe essere in grado di accedere ai dati dalla sessione (preferibilmente tramite un'interfaccia) ed è la visione che non dovrebbe accedervi (rimanendo stupido)?

Answer 4

Dipende dall'oggetto che si sta tentando di riutilizzare o altrimenti contiene la maggior parte della logica aziendale.

Suppongo che solo il relatore dovrebbe conoscere la sessione in quanto l'oggetto è l'elemento più vicino a un controller in MVP.

Answer 5

Sì, come dice Colomba, avvolgi qualsiasi cosa acceda alla Sessione in un'altra classe.

Ciò significa che è possibile iniettare una classe simulata di questo tipo per simulare valori diversi per Session.

Per rispondere alla tua domanda in modo più specifico, tendo a scegliere il modello Supervising-Presenter ( http: / /martinfowler.com/eaaDev/SupervisingPresenter.html ), che mantiene le visualizzazioni MOLTO stupide. Quindi solo il Presentatore accederà alla Sessione (anche se non direttamente come ho detto prima) e dirà a View cosa fare.

Answer 6

Sto anche studiando approcci MVP passivi. Ho visto un paio di cose fatte sul web, entrambe le quali lasciano la persistenza della sessione fino alla vista - attraverso l'iniezione, come ha detto colomba, o la gestione esplicita.

Esempi di iniezione di dipendenza sono disponibili qui: http://www.codeproject.com /KB/aspnet/Advanced_MVP.aspx e qui: http : //geekswithblogs.net/opiesblog/archive/2006/06/30/83743.aspx . Il trucco qui è gestire tutte le istanze della sessione in una variabile statica e impedire che si sovrascrivano a vicenda. (Non sono sicuro che il primo esempio lo realizzi correttamente.)

Il secondo approccio è qui: http: / /codebetter.com/blogs/jeffrey.palermo/archive/2005/03/28/128592.aspx . In questo esempio la vista sa come memorizzarne lo stato. Il rovescio della medaglia è che ogni volta che il presentatore inserisce i dati nella vista, è necessario chiamare un metodo di aggiornamento nella vista per forzare il rebinding. Questo non è necessario negli esempi sopra, ma non è necessario gestire un tavolo di sessioni. Non sono sicuro di come questo approccio complichi i test con strumenti beffardi.

Answer 7

Il consiglio è di interfacciare ogni entità consumabile. Rende il presentatore e il modello più facili da testare con derisione e focalizzare i test sul comportamento.