MVP (Model View Presenter) o MVC (Model View Controller)

Question

Conosco già la differenza tra MVP e MVC. Quindi, anche dopo aver esaminato l'SRS di un'applicazione, ottengo una correzione che deve essere selezionata, applicata e seguita come architettura di applicazione. Secondo la mia comprensione, selezionerei MVP dove ci sono le possibilità di usare la stessa logica di business, da più di 2 GUI. Come per un'applicazione con una parte pubblica (www) e Adming (winform). Se non c'è tale ... cerca MVC. Perché posso seguire in modo più accurato i pattern di fabbrica.

Dudes, non lo so, ma mi sento come se stessi giocando a blind se dovessi scegliere tra loro. Ho bisogno di sapere. Che opinione avete su questi?

Nota: seguo .net e C#.

Answer 1

Nella mia mente le differenze per tutte le varianti di modelli Model View Controller (MVP, Passive View, Supervising Controller, Vista Modello, etc.) sono abbastanza sottili. Si tratta di chi elabora i dati e prende i dati da chi, davvero. Stanno tutti cercando di risolvere lo stesso problema, separando qualcosa da da un'altra cosa, e le soluzioni fanno tutto ciò in modo simile.

E 'quasi palesemente evidente che i concetti sono simili in esecuzione quando si pensa a questo proposito in termini visivi:

Simplistic MVC: 

+-------+  manipulates data 
| Model |<---------------------+ 
+-------+      | 
    |       | 
    | gets data    | 
    v       | 
+------------+ serves data +------+ 
| Controller |------------->| View | 
+------------+    +------+ 

Simplistic MVP: 

+-------+ 
| Model | 
+-------+ 
    |^
    | | get/manipulates data 
    v | 
+-----------+ serve data +------+ 
| Presenter |-------------->| View | 
|   |<--------------|  | 
+-----------+ tell changes +------+ 

Sono simili in quanto gerarchia di classe può sembrare lo stesso in entrambi. La differenza tuttavia sono i diversi modi di visualizzare e manipolare i dati. Quando stai distribuendo il tuo MVC, allora sei il responsabile di come dovrebbe essere.

Non ha molta importanza poiché si basano tutti su un principio di separazione di parti di codice in entità logiche self-service e riduzione della duplicazione del codice. Finché si mantiene il code coupling low dovrebbe funzionare bene alla fine. Importa solo se vuoi essere dogmaticamente conseguente all'architettura della tua applicazione.

Essere pragmatici al riguardo e fare ciò che più si addice ai tuoi bisogni, visto che finirai comunque con un mix. Dovrebbe essere "abbastanza" facile passare da una variazione all'altra a seconda delle esigenze della vista. Seguire i principi SOLID e si dovrebbe fare bene. (Vedi anche this about SOLID).

Vorrei suggerire di esaminare se esistono quadri MVC o MVP per vedere come è fatto.

Answer 2

Penso che tu sia sulla strada giusta qui. MVP per le app con più di una GUI e MVC per le app Web è la mia linea guida generale. Se ne fai uno, utilizzerei un framework come ASP .Net MVC o Castle's MonoRail perché fare l'impianto idraulico da solo può essere un problema. C'è una buona implementazione di riferimento di MVC here basata sul database Northwind fornito con SQL Server 2000.

http://nsk.codeplex.com/SourceControl/list/changesets