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

Question

Ich kenne bereits den Unterschied zwischen MVP und MVC. Dann auch nach dem Durchgehen durch die SRS einer Anwendung bekomme ich in einem Fix, die eine ausgewählt werden müssen, angewendet und als Applcation Architektur gefolgt. Nach meinem Verständnis würde ich MVP wählen, wenn die Möglichkeit besteht, die gleiche Geschäftslogik in mehr als 2 GUIs zu verwenden. Zum Beispiel für eine Anwendung mit einem öffentlichen (www) und einem Adming (winform) Teil. Wenn es nicht solche ... suchen für MVC. Weil ich Factory Patterns genauer folgen kann.

Leute, ich weiß nicht, aber ich habe das Gefühl, dass ich einfach blind drauflos schießen würde, wenn ich mich zwischen ihnen entscheiden müsste. Ich muss es wissen. Welche Meinung habt ihr über diese?

Anmerkung: Ich arbeite mit .net und C#.

Answer 1

Meiner Meinung nach sind die Unterschiede bei allen Varianten von Model-View-Controller-Mustern ( MVP , Passive Ansicht , Überwachender Controller , Ansicht Modell, usw. ) sind recht subtil. Es geht eigentlich nur darum, wer die Daten verarbeitet und von wem die Daten genommen werden. Sie alle versuchen, das gleiche Problem zu lösen, nämlich die Trennung von algo de noch etwas und die Lösungen tun dies alles auf ähnliche Weise.

Es ist fast offensichtlich, dass die Konzepte in der Umsetzung ähnlich sind, wenn man sie visuell betrachtet:

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

Sie sind sich insofern ähnlich, als dass die Klassenhierarchie in beiden gleich aussehen kann. Der Unterschied liegt jedoch in der unterschiedlichen Art und Weise, wie Daten angezeigt und bearbeitet werden. Wenn Sie Ihr eigenes MVC-System einführen, sind Sie dafür verantwortlich, wie es aussehen soll.

Es spielt eigentlich keine große Rolle, da sie alle auf dem Prinzip der Trennung von Codeteilen in selbständige logische Einheiten und der Verringerung von Code-Duplizierung beruhen. Solange Sie die Codekopplung niedrig sollte es am Ende gut funktionieren. Es ist nur von Bedeutung, wenn Sie die Architektur Ihrer Anwendung dogmatisch konsequent umsetzen wollen.

Seien Sie pragmatisch und entscheiden Sie sich für das, was Ihren Bedürfnissen am besten entspricht, denn am Ende werden Sie sowieso eine Mischung haben. Es sollte "ziemlich" einfach sein, zwischen den Varianten zu wechseln, je nachdem, was die Ansicht braucht. Befolgen Sie die SOLID Prinzipien und Sie sollten gut zurechtkommen. (Siehe auch dies über SOLID ).

Ich würde vorschlagen, dass Sie nachschauen, ob es MVC- oder MVP-Frameworks gibt, um zu sehen, wie es gemacht wird.

Answer 2

Ich denke, Sie sind hier auf dem richtigen Weg. MVP für Anwendungen mit mehr als einer grafischen Benutzeroberfläche und MVC für Webanwendungen ist meine allgemeine Leitlinie. Wenn Sie eines von beiden tun, würde ich ein Framework wie ASP.Net MVC oder Castle's MonoRail verwenden, weil die Klempnerarbeit auf eigene Faust ein Schmerz sein kann. Es gibt eine gute Referenzimplementierung von MVC aquí basierend auf der Northwind-Datenbank, die mit SQL Server 2000 geliefert wurde.

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