Frage

Ich habe eine ziemlich gute Idee, wie jedes dieser Muster über einige der kleinen Unterschiede zwischen ihnen funktioniert und weiß, aber unterscheiden sie sich wirklich so voneinander?

Es scheint mir, dass der Moderator, das Präsentationsmodell, das ViewModel und der Controller im Wesentlichen das gleiche Konzept sind.

Warum konnte ich nicht all diese Konzepte als Controller klassifizieren? Ich habe das Gefühl, dass es die gesamte Idee sehr vereinfachen könnte.

Kann jemand eine klare Beschreibung seiner Unterschiede geben?

Ich möchte klarstellen, dass ich verstehe, wie die Muster funktionieren, und die meisten von ihnen in der einen oder anderen Technologie implementiert haben. Was ich wirklich suche, ist die Erfahrung von jemandem mit einem dieser Muster und warum sie sein ViewModel beispielsweise nicht als Controller betrachten würden.

Ich werde einige Rufpunkte dafür geben, aber ich suche eine wirklich gute Antwort.

War es hilfreich?

Lösung

Neben den bereits erwähnten großartigen Reads (Fowler & Miller) und auf Ihren Punkt auf Unterschiede zwischen Controller/ Moderator/ ... Aus der Sicht des Entwicklers:

Controller in MVC:

  • Controller ist die tatsächliche Komponente, die als Ergebnis der Benutzerinteraktion aufgerufen wird. (Der Entwickler muss keinen Code schreiben, um Anrufe an den Controller zu delegieren.)

  • Controller erhält die aktuellen Werte irgendwie aus Ansicht/ Kontext/ Tasche/ was auch immer, aber Sie würden das nicht wirklich sagen interagiert mit der Aussicht.

  • Controller entscheidet am Ende, welche Ansicht den Benutzer zurückzeigt. Dabei zeigt Controller auch einen expliziten Begriff des Anwendungsnavigations -Workflows.

Moderator in MVP:

  • Der Präsentator hat Methoden, die von der Ansicht aufgerufen werden, nämlich die tatsächliche Komponente, die die Kontrolle über die Benutzerinteraktion empfängt. (Der Entwickler muss einen Code in der Ansicht schreiben, um den Moderator anzurufen.)

  • Der Moderator erhält die aktuellen Werte irgendwie aus der Ansicht oder empfangen sie aus der Ansicht auf den Anruf. Moderator ruft Methoden in der Ansicht auf, um seinen Status festzulegen (bevölkern sagt Josh Smith). Eine vom Moderator genannte Ansichtsmethode könnte Lassen Sie mehrere kleine Einstellungen in seinem Körper ausführen.

  • Der Moderator zeigt keinen expliziten Begriff des Anwendungsworkflows. Es wird normalerweise als zurückkehrende Kontrolle für die Anrufansicht betrachtet.

PräsentationModel in PM:

  • PresentionModel verfügt über Methoden, die von der Ansicht genannt werden. Dies ist die tatsächliche Komponente, die die Kontrolle über die Benutzerinteraktion empfängt. (Der Entwickler muss einen Code in der Ansicht schreiben, um das PräsentationModel aufzurufen.)

  • PräsentationModel hat viel mehr gesprächig Kommunikation mit Sicht im Vergleich zu einem Moderator. Es enthält auch mehr Logik, um den Wert aller Einstellungen in der Ansicht zu ermitteln und diese tatsächlich in der Ansicht festzulegen. (Diese Ansichtsmethoden haben abwechselnd fast keine Logik.)

  • PresentionModel zeigt keinen explizit einen Begriff des Anwendungsworkflows. Es wird normalerweise als zurückkehrende Kontrolle für die Anrufansicht betrachtet.

ViewModel in MVVM:

  • ViewModel verfügt über Methoden, die von der Ansicht mit dem Namen (& Eigenschaften eingestellt) aufgerufen wurden. Dies ist die tatsächliche Komponente, die bei der Benutzerinteraktion die Steuerung empfängt. (Der Entwickler muss einen (deklarativen) Code in die Ansicht schreiben, um das ViewModel aufzurufen.)

  • ViewModel hat im Vergleich zu PräsentationModel keine explizit gesprächige Kommunikation mit der Ansicht (dh es wird nicht viel bezeichnet, das Framework tut es). Es gibt jedoch viele Eigenschaften, die 1 bis 1 mit Ansichtseinstellungen zubereiten. Es enthält immer noch die gleiche Logik, um den Wert all dieser Einstellungen herauszufinden.

  • ViewModel zeigt keinen expliziten Begriff des Anwendungsworkflows. Es wird normalerweise als zurückkehrende Kontrolle für die Anrufansicht betrachtet.

  • Irgendwie kopieren, was Josh Smith sagt (http://msdn.microsoft.com/en-us/magazine/dd419663.aspx): MVVM -Muster ist ein Sonderfall von PM, der ein Framework (wie WPF/SL) nutzt, um weniger Code zu schreiben.

Andere Tipps

Martin Fowler hat eine Seite zu UI -Designmustern, in der er MVC, MVP und andere Muster definiert und dann spricht.

http://martinfowler.com/eaadev/uiarchs.html

EIN Regler ist aktiv bei der Kontrolle der Benutzeroberfläche. Zum Beispiel würde es alle von der Benutzeroberfläche ausgelösten Ereignisse behandeln und sich angemessen mit ihnen befassen.

EIN Moderator Andererseits ist passiver und zeigt nur Daten über die Benutzeroberfläche an, die ihre eigenen Ereignisse usw. behandelt, oder delegiert sie über den Moderator zu einem Dienst oder Befehl.

EIN ViewModel ist ein spezifisches Beispiel für einen Präsentanten, der für die Verwendung mit WPF/Silverlight -Bindung ausgelegt ist.

EIN Präsentationsmodell ist ein Modell, das direkt aus der Ansicht dargestellt werden kann. Wenn Ihre Modelle beispielsweise inotifyPropertyChanged für die Datenbindung implementieren, wären sie Präsentationsmodelle.

Der Unterschied zwischen ihnen liegt im Wesentlichen darin, wie viel Code in der Ansicht liegt. Die Wahl zwischen ihnen ist in der Tat eine Auswahl der Technologie für Anwendung wie WFP, WinForms, ASP MVC (2). Die Grundidee der Trennung der Logik von der Präsentation ist gleich.

Hier ist ein sehr guter Artikel über alle drei.

BEARBEITEN:

Einer Mehr Artikel - Vergleich.

Zumindest in .NET wird MVP als Designmuster verwendet. Dies wird normalerweise mit Windows Forms -Anwendungen oder klassischem ASP.NET verwendet. Bei MVC und MVVC werden diese normalerweise mit ASP MVC verwendet, das eine ziemlich andere Architektur verwendet als normale ASP.NET.

Meiner Meinung nach gibt es keine wirklichen konzeptionellen Unterschiede zwischen MVP, MVVC, MVC und Präsentationsmodell. Es gibt einige detaillierte Unterschiede, aber am Ende kann es alle weiterhin als Modellansichts -Controller -Setup betrachtet werden. Die zusätzliche Benennung dient nur dazu, Verwirrung zu erzeugen, und ich denke, es wäre besser, Terminologie zu übernehmen, die eine bestimmte Menge an Breitengrad bei der Beschreibung eines Controllers ermöglicht.

Eine wichtige Unterscheidung zwischen MVP und MVVM ist die Art und Weise, wie die Ansicht keine aktive Rolle bei der Aktualisierung der mittleren Schicht spielt, und ist ein "dummer" Schauspieler als Ansicht für die Anzeige und nicht für das Verhalten. Der Moderator wird für Ansichten empfohlen, die "komplex" sind, dh:

  • Wenn Sie das Klick behandeln, indem Sie die Aktivität („Navigation“) ändern, ist es beim Moderator einfacher
  • Änderungen der Ansichtsänderungen gemäß Data Layer Update (ASYNCH) werden am besten mit ViewModel implementiert

Refs:

https://developer.android.com/topic/libraries/architecture/lifecycle#lc-bp

https://android.jlelse.eu/why-to-choose-mvm-over-mvp-forchitecture-33c0f2de5516 enter image description here

enter image description here

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top