Costruire siti Web, quale è l'approccio migliore MVP o MVC?

Suppongo che tu stia chiedendo nel contesto del mondo Microsoft?

Ho capito che MVP era principalmente impiegato per testare le unità i controllori dell'applicazione. Penso che un altro termine per lo schema MVP sia Supervising Presenter.

La vista in questo caso sarebbe la pagina ASP, che avrebbe un'istanza del Presenter, e qualsiasi evento nella pagina (ad esempio il gestore di clic) delegherebbe il loro lavoro al Presenter. Il Presenter avrebbe un riferimento alla Vista (sebbene attraverso un'interfaccia IView che la Pagina avrebbe implementato). Il Presenter risponderebbe quindi alle azioni dalla vista, fare qualcosa, aggiornare il modello e passarlo nuovamente alla vista o eseguire azioni sulla vista tramite l'interfaccia.

Questo aiuta a testare le unità, perché il Presenter (dove dovrebbe essere una qualsiasi logica di presentazione) può avere il mocking della vista. Tipicamente, un Presenter avrebbe anche riferimenti ad altri servizi, che dovrebbero fare affidamento sull'integrazione delle dipendenze (tramite IMO di constructor injection) per consentire anche a Presenter di essere testato separatamente (un corretto test unitario).

Il motivo principale per cui penso di utilizzare MVP nei WebForm di ASP.NET è perché la classe Page è legata al runtime di ASP.NET , mentre ASP.NET MVC ha astrazioni su cose come HttpRequest e le classi controller e ActionResult possono essere testate in modo isolato, non è necessario utilizzare MVP: l'unità è testabile per impostazione predefinita.

Quindi per rispondere (penso): userei MVP se stavo usando WebForms, per aiutare la testabilità. Altrimenti userei MVC.

Guarda anche Factory Software Web Client , che offre un framework per un punto di partenza per l'implementazione del pattern MVP.

Ci sono modi per fondere i due. Per esempio con ASP.NET MVC puoi usare il normale pattern MVC, ma hanno le Views strongmente vincolate a un ViewModel (come in MVVM, un discendente di MVP). Ciò offre i vantaggi di MVP (ovvero, disaccoppia la vista dalle specificità del modello di dominio) pur avendo anche un livello dedicato per gestire gli eventi.

Non ho ancora provato ad applicarlo al di fuori di .NET,

Dipende da cosa stai facendo. Se sei bloccato usando WebForms, MVP è la tua unica vera scelta per fare le cose correttamente con quella bestia. Se è possibile utilizzare MVC, utilizzarlo, altrimenti utilizzare MVP o alcune varianti di esso.

Alla fine della giornata, la cosa migliore è, come sempre, dipendere da ciò che stai sviluppando.

Dichiarazione di non responsabilità: non ho davvero cercato su MVP tutti che molto, ma da quello che ho letto ...

Mi sembra che il modello MVP possa avere senso in un'applicazione in cui il client è responsabile di quelle che altrimenti sarebbero azioni del controller MVC come il salvataggio, la modifica, la cancellazione ecc. tramite AJAX (o websocket) - l'importanza è che la logica di business si svolge all'interno del client (la vista è responsabile per) javascript.

Personalmente, lo considererei un progetto scadente se la vista (in qualsiasi linguaggio di backend) contenesse la logica per le transazioni del database. Ho come il disaccoppiamento offerto dal pattern MVC, rendendo le visualizzazioni il più stupide possibile. Per me, MVP sembra quasi fare un passo indietro nelle pratiche di sviluppo.

Solo la mia opinione però:)