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

Question

Je connais déjà la différence entre MVP et MVC. Ensuite, après avoir passé le SRS d'une application, j'obtiens un correctif qui doit être choisi, appliqué et suivi comme Applcation Architecture. Selon ce que je comprends, je choisirais MVP où il y a des chances d'utiliser la même logique métier, à partir de plus de 2 interfaces graphiques. Comme pour une application avec une partie publique (www) et Adming (winform). Si ce n'est pas le cas ... recherchez MVC. Parce que je peux suivre les règles d'Usine avec plus de précision. Dudes, je ne sais pas mais j'ai l'impression de jouer à l'aveugle si je devais choisir parmi eux. J'ai besoin de savoir. Quelle opinion avez-vous sur ces choses?

Remarque: Je suis .net et C#.

Answer 1

Dans mon esprit les différences pour toutes les variantes de Model View Controller (modèles MVP, Passive View, Supervising Controller, Vue modèle, etc.) sont assez subtiles. Tout dépend de qui traite les données et prend les données de qui, vraiment. Ils essaient tous de résoudre le même problème, séparant quelque chose de une autre chose, et les solutions font tout cela d'une manière similaire.

Il est presque évident que les flagrante concepts sont similaires dans la mise en œuvre quand on y pense en termes visuels:

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 +------+ 

Ils sont similaires dans cette hiérarchie de classe peuvent regarder la même dans les deux. La différence est cependant les différentes façons d'afficher et de manipuler les données. Lorsque vous déployez votre propre MVC, vous êtes responsable de son apparence.

Cela n'a pas vraiment d'importance, car ils reposent tous sur le principe de la séparation des parties de code en entités logiques individuelles et de la réduction de la duplication de code. Tant que vous gardez le code coupling low il devrait bien fonctionner à la fin. Cela n'a d'importance que si vous voulez être dogmatiquement conséquent avec l'architecture de votre application. Soyez pragmatique et faites ce qui convient le mieux à vos besoins, car vous finirez quand même avec un mixage. Il devrait être "assez" facile de basculer entre les variations en fonction de ce que la vue a besoin. Suivez les principes SOLID et vous devriez faire bien. (Voir aussi this about SOLID).

Je vous suggère de vérifier s'il existe des frameworks MVC ou MVP pour voir comment cela est fait.

Answer 2

Je pense que vous êtes sur la bonne voie ici. MVP pour les applications avec plus d'une interface graphique et MVC pour les applications Web est mon guide général. Si vous faites l'un ou l'autre, j'utiliserais un framework tel que ASP .Net MVC ou le MonoRail de Castle car faire la plomberie seul peut être pénible. Il y a une bonne implémentation de référence de MVC here basé sur la base de données Northwind fournie avec SQL Server 2000.

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