Unterschied zwischen MVVM und MVP

Der Zweck der Softwareentwicklung besteht darin, Lösungen zu entwickeln, die auf die Bedürfnisse und Probleme von Benutzern und Unternehmen eingehen. Um dies zu erreichen, mögen verschiedene Technologien und Architekturmuster Model-View-ViewModel (MVVM) und Model-View-Presenter (MVP) werden verwendet.

Wie bei allem, was hergestellt wird, ist der erste Schritt die Planung und Planung. Der Software-Designprozess kann eine Spezifikation sein, die auf dem bevorzugten Technologie-Tool-Set basiert, und kann alle Aktivitäten von der Konzeption über die Planung bis zur Implementierung bis hin zu Updates und Änderungen umfassen.

Es deckt das Architekturdesign auf niedriger und höherer Ebene ab, das auf ausgewählten Architekturmustern basiert, und bildet wiederverwendbare Lösungen anhand von Designmustern ab.

Software-Anwendungsstruktur

Die Softwarearchitektur definiert die Struktur einer Anwendung, die technische, betriebliche und Benutzeranforderungen erfüllt, und gibt an, wie der Code organisiert und verwaltet wird.

Die Entscheidung für die Architektur einer Softwareanwendung ist entscheidend, da sie nicht einfach und veränderbar in einer bereits entwickelten Anwendung ist. Daher muss das architektonische Muster vor Beginn der Programmierung festgelegt werden.

Architektonische Muster unterscheiden sich etwas von den Entwurfsmustern, da ihr Anwendungsbereich viel breiter ist, indem mehr technische Probleme wie Hardwareleistung und -beschränkungen sowie hohe Verfügbarkeit angesprochen werden. Beispiele für unterschiedliche Architekturmuster sind MVC, MVVM und MVP.

Andererseits sind Entwurfsmuster formalisierte Best Practices, die eine wiederverwendbare objektorientierte Entwicklung erleichtern und einfacher zu warten und zu ändern sind als die Architektur einer Anwendung. 

Architekturmuster

Modellansicht-Controller (MVC) war eines der ersten architektonischen Muster, die für Webanwendungen entwickelt wurden, und wurde von Mitte bis Ende der Neunzigerjahre immer beliebter, insbesondere bei der Java-Community.

Bei den neueren Frameworks wie Django für Python und Rails (Ruby on Rails) liegt der Fokus auf einer schnellen Implementierung. Daher nimmt MVC den Marktanteil als Hauptanziehungspunkt bei Architekturmustern auf.

Traditionell enthielt die Entwicklung von Benutzeroberflächen eine Menge Code für die Handhabung komplizierter Logik, so dass Architekturmuster entworfen wurden, um den Code auf der Benutzeroberflächenebene zu reduzieren, wodurch er "sauberer" und handhabbarer wird.

Mit dem MVC-Muster besteht eine Webanwendung also aus

• Modell (Daten)
• Aussicht (Schnittstelle zum Anzeigen und Bearbeiten von Daten)
• Regler (Operationen und Aktionen an den Daten)

Das Modell verarbeitet Daten und Geschäftslogik und das gibt es Nein Abhängigkeiten zwischen dem Modell und das Regler oder Aussicht.

Das Aussicht präsentiert dem Benutzer die Daten in dem unterstützten Format und dem erforderlichen Layout und wann Regler Empfängt Benutzeranfragen (um Daten abzurufen), ruft sie die relevanten Ressourcen auf, die zum Abschließen der Anforderung erforderlich sind.

Wenden wir dieses Muster für den Aufbau einer Online-Buchhandlung an.

Benutzer können Bücher suchen, anzeigen, registrieren und kaufen sowie ihre Profile und Buchlisten verwalten. Wenn ein Benutzer auf die Kategorie SCI-FI klickt, sollten alle zugehörigen Bücher als verfügbar angezeigt werden.

Das Controller die Aktionen verwalten, die die Bücher verwalten (Liste, Hinzufügen, Anzeigen usw.). Es kann mehrere geben Controller mit einem haupt Regler 'den Verkehr lenken'.

Für dieses Beispiel die Regler heißt controller_books.php und die Modell (z. B. model_books.php) behandelt die Daten und die Logik, die sich auf die Bücher beziehen.

Schließlich anders Ansichten Dies ist beispielsweise erforderlich, wenn Sie Bücher zum Online-Warenkorb hinzufügen oder das Buchdetail mit Bildern und Rezensionen anzeigen.

Das controller_books.php empfängt die Aktion (Benutzeranfrage) vom Hauptmenü Regler (z.B. index.php). Das controller_books.php analysiert die Anfrage und ruft das an model_books.php (die Daten), um die Liste der SCI-FI-Bücher zurückzugeben.

Die Verantwortung der Modell dient dazu, diese Informationen unter Verwendung einer beliebigen Logik (mithilfe von Suchfiltern) bereitzustellen. Das Regler dann nimmt die Information und leitet sie an das relevante weiter Aussicht (Suchansicht, Druckansicht, Detailansicht usw.) und die Informationen werden angezeigt (über die Aussicht) an den Benutzer, der die Anfrage initiiert hat.

Dies ist die Grundlage des MVC-Musters, bei dem sich die Variationen von Architekturmustern verändert haben, z. B. Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Hierarchical-Model-View-Controller (HMVC) und Model-View-Adapter (MVA) usw.

MVP-Muster

Model-View-Presenter (MVP)

Das MVP-Muster gibt es schon eine Weile und ist eine Variante von MVC. Es wurde speziell für die Testautomatisierung entwickelt, bei der das Ziel bestand, die Menge an Code, die durch Automatisierung getestet werden kann, zu erhöhen. Das Muster behebt einige Probleme mit der Präsentationsschicht und isoliert die Geschäftslogik von der Benutzeroberfläche.

Der Bildschirm ist die Ansicht, die angezeigten Daten sind das Modell, und der Presenter verbindet die beiden.

MVP umfasst die folgenden Komponenten mit separaten Verantwortlichkeiten:

• Modell (definiert die anzuzeigenden Daten)
• Aussicht (zeigt die Daten des Modells an und leitet Benutzeranfragen an den Presenter weiter).
• Moderator (interagiert zwischen Ansicht und Modell und hakt sie zusammen)

Das Aussicht (eine Webseite) zeigt die Seitensteuerelemente an und verwaltet sie durch Weiterleiten von Ereignissen (Benutzeranforderungen) an Moderator das wurden in der initiiert Aussicht.

Das Moderator reagiert auf diese Ereignisse durch Lesen und Aktualisieren der Modell um es zu ändern Aussicht und deshalb die Moderator Verantwortung ist es, die zu binden Modell und Aussicht.

Nach dem Anschauen MVC und MVP Muster, die Gemeinsamkeit ist für jede Komponente getrennt und sie fördern die Trennung zwischen den Aussicht (UI) und Modell (Daten). Signifikante Unterschiede zwischen diesen Mustern zeigen sich deutlicher bei der Implementierung der Muster.

MVP Es kann ein komplexes Muster sein, das für fortgeschrittene Lösungen zu implementieren ist, hat aber sicherlich große Vorteile, wenn es als gut konzipierte Lösung implementiert wird, obwohl es nicht unbedingt die geeignete Wahl für einfache Lösungen ist.

MVVM-Muster

Model-View-ViewModel (MVVM)

Das MVVM Muster wurde speziell für Windows Presentation Foundation (WPF) und Microsoft Silverlight-Plattformen entwickelt und kann auf allen verwendet werden XAML [i] Plattformen.

WPF ist ein Microsoft-System, das Benutzeroberflächen in Windows-basierten Programmen darstellt und erstmals in .NET Framework 3.0 veröffentlicht wurde.

MVVM wurde verfeinert MVC und in diesem Muster die Aussicht ist aktiv mit Verhalten, Ereignissen und Datenbindung sowie dem Aussicht synchronisiert mit dem ViewModel (Dies ermöglicht die Trennung der Präsentation und macht Methoden und Befehle zur Verwaltung und Bearbeitung des Modell.

MVVM besteht aus drei Kernkomponenten:

• Modell (repräsentiert die Daten mit Validierung und Geschäftslogik)
• Aussicht (Die Ansicht ist für die Definition der Struktur, des Layouts und des Erscheinungsbilds des Benutzers auf dem Bildschirm verantwortlich. Idealerweise wird die Ansicht ausschließlich mit XAML definiert, wobei ein eingeschränkter Code-Behind hinter der Geschäftslogik steht. Bindung zwischen dem Aussicht und ViewModel Anzeigen von Werten, die das Modell und das ViewModel mit der View synchronisieren)
• ViewModel (trennt die Ansicht vom Modell und stellt Methoden und Befehle zum Bearbeiten der Daten bereit (Modell).

Das Aussicht empfängt Daten vom ViewModel (durch Datenbindung und Methoden) und zur Laufzeit die Aussicht ändert sich, wenn Sie auf Ereignisse im reagieren ViewModel.

Das ViewModel vermittelt zwischen dem Aussicht und Modell und behandelt die Aussicht Logik. Es interagiert mit dem Modell - die Daten aus dem Modell und präsentiere es dem Aussicht anzeigen.

Diese Komponenten sind alle voneinander entkoppelt, was eine größere Flexibilität ermöglicht, unabhängig voneinander zu arbeiten, Komponententests zu isolieren und auszutauschen, ohne die anderen Komponenten zu beeinträchtigen.

Diese Struktur erlaubt das Modell und andere Komponenten können unabhängig voneinander entwickelt werden, sodass Entwickler gleichzeitig an verschiedenen Aspekten der Lösung arbeiten können. Zum Beispiel, wo Designer am arbeiten Aussicht, Sie generieren einfach Datenmuster, ohne auf die anderen Komponenten zugreifen zu müssen. Dies erleichtert die Neugestaltung der Benutzeroberfläche als Aussicht ist in XAML implementiert.

Wie schon erwähnt mit MVP, Für einfache Lösungen sind keine Architektur- und Designmuster erforderlich, zum Beispiel ist "Hello World!" zu einfach, um einem Muster zu folgen. Mit der Einführung weiterer Funktionen, Funktionen und Komponenten steigt jedoch die Komplexität der Anwendung und damit auch die Menge an Code, die verwaltet werden muss.

In Summe

Seit Beginn der Entwicklung der Benutzeroberfläche werden Designmuster immer beliebter, um den Entwicklungsprozess zu vereinfachen, die Anwendungen skalierbarer zu machen und das Testen zu vereinfachen.

Illustrierter Unterschied zwischen den MVP- und MVVM-Mustern:

• Sowohl MVP und MVVM, das Aussicht ist der Einstiegspunkt in die Anwendung
• Im MVP, Es gibt eine Eins-zu-Eins-Zuordnung zwischen dem Aussicht und Moderator, wo in MVVM, Die Beziehung ist Eins-zu-Viele zwischen den Aussicht und ViewModel.
• MVP wird hauptsächlich für Windows Forms und Windows Phone-Anwendungen verwendet MVVM ist für Silverlight, WPF, Knockout / AngularJS usw. konzipiert.