it-swarm.com.de

Sollten eine Ansicht und ein Modell kommunizieren oder nicht?

Gemäß der Wikipedia-Seite für die MVC-Architektur kann die Ansicht vom Modell benachrichtigt werden und das Modell kann auch nach seinem aktuellen Status abgefragt werden. Laut Paul Hegartys Kurs über iOS 5 in Stanford, Vorlesung 1, Seite 18 muss jedoch jede Interaktion über den Controller erfolgen, wobei Model und View sich niemals kennen sollen. Es ist mir nicht klar, ob Hegartys Aussage als Vereinfachung für den Kurs gedacht sein muss, aber ich bin versucht zu sagen, dass er das Design als solches beabsichtigt.

Wie erklären Sie diese beiden gegensätzlichen Sichtweisen?

33
Stefano Borini

Dies ist ein kontroverses Thema in MVC/MVVM. Einige sagen, dass es in Ordnung ist, dass die Ansicht direkt auf die Modelle zugreift, andere sagen, dass Sie die Modelle in ViewModels einschließen sollten, um sie von der Ansicht zu abstrahieren. Ich persönlich bin kein Fan von beiden Ansätzen.

Eines der Hauptziele von MVC/MVVM ist die Entkopplung von Benutzeroberfläche, Geschäftslogik und Daten. Wenn Sie also dieses Konzept berücksichtigen und der Ansicht den direkten Zugriff auf die Modelle ermöglichen, entsteht eine Abhängigkeit, die Sie möglicherweise nicht haben möchten. Andererseits ist das Umschließen der Modelle in ViewModels oft mühsam und nicht sehr nützlich, da die ViewModels in der Regel lediglich als Durchgang zu den Modellen dienen.

Ich mag den Ansatz, dass Ihre Modelle eine bestimmte Schnittstelle implementieren, nennen wir es IModel. Ihre ViewModel-Klasse kann dann Instanzen von Objekten anbieten, die IModel für den View-Verbrauch implementieren. Die Ansicht weiß einfach, dass sie mit IModel-Objekten funktioniert, die sie vom ViewModel erhält. Dadurch wird der überflüssige ViewModel-Wrapper-Code entfernt und die konkrete Implementierung von IModel aus der Ansicht ausgeblendet. Sie können später eine Implementierung von IModel gegen eine andere austauschen, ohne die Ansicht ein Bit zu beeinflussen.

26

Im Web nennt jeder seine Entkopplungs-MVC.

Einige Technologien, wie z. B. C #, verwenden MVVM, da keine Verbindung zwischen der Ansicht und anderen besteht. Alles läuft über den Service Locator und bindet die Variablen.

Bei reiner MVC kommuniziert die Ansicht direkt mit dem Modell und umgekehrt. Der Controller ist nur da, wenn sich etwas ändert.

Und dann gibt es noch die PAC (Presentation Abstraction Control). In dieser Architektur sprechen die Ansicht und das Modell nicht miteinander. Der Controller ist der einzige, der mit der Ansicht oder dem Modell etwas tun darf. Die Leute verwechseln dies oft mit MVC.

Eine bessere Erklärung finden Sie hier: http://www.garfieldtech.com/blog/mvc-vs-pac

12

Für mich ist das grundlegende Ziel einer Architektur, zukünftige Refactoring-Versuche nicht zu behindern. In der Regel erfüllen Ansichten, die direkt mit Modellen interagieren, diese Anforderung, und es ist relativ klar, wenn dies nicht der Fall ist.

Wenn eine Ansicht mit einem Modell zu intim wird, kann ein ViewModel eine schöne Sache sein, aber für mich ist es normalerweise so, dass die Fälle, in denen es erforderlich ist, in der Minderheit sind.

7
menacingly

In MVC ist Paul Hegarty falsch. Beim Controller geht es um Benutzerereignisse, nicht um die Kommunikation zwischen Modell und Ansicht. Im klassischen MVC beobachten die Ansichten das Modell (Beobachtermuster).

Mit dem Mann dazwischen, der die Mediation durchführt, sollte das Muster MVP heißen, und tatsächlich ist das meiste, was heutzutage als MVC dargestellt wird, tatsächlich näher zu MVP.

Dann gibt es MVVM , das beiden ähnlich und doch etwas anders ist und vor langer Zeit existiert hat ... es ist am besten, es als zwei zu sehen MVCs/MVPs, die über das viewmodel-Objekt miteinander verbunden sind - die MVC "Client" hat das Viewmodel als Modell und die MVC "Server" das Viewmodel als Ansicht.

6
herby

Da Sie insbesondere nach dem Material in diesen Stanford-Vorlesungen fragen, sollten Sie zwei Dinge über Hegartys Haltung in Betracht ziehen:

  1. Wie Sie bereits erwähnt haben, unterrichtet er einen 100-Level-Computer-Sci-Kurs. Es gibt viele Stellen in seinen Vorlesungen, an denen er Details vereinfacht, beschönigt oder sagt: "Mach es einfach so", wie man es wahrscheinlich beim Unterrichten der Grundlagen tun muss, d. H. Man muss die Regeln beherrschen, bevor man sie brechen kann.
  2. Meine Erfahrung mit dem iOS SDK ist, dass es, wo es nicht erzwingen strikte Trennung zwischen Ansicht und Modell, stark auf dieses Muster ausgerichtet ist. Insbesondere beim Schreiben von iOS-Apps können Sie durch Einhaltung der Trennung von Modellansichten Code schreiben, der den Erwartungen des Frameworks entspricht. Ich würde zögern, Hegartys Aussagen auf die Entwicklung auf anderen Plattformen oder allgemein zu verallgemeinern.
4
Dan J

Ich glaube, dass es dafür keine feste Regel gibt, es hängt ganz von Ihren Bedürfnissen ab.

Sie werden Menschen mit unterschiedlichen Überzeugungen finden. Architekturen sind Konzepte, mit denen bessere Lösungen entworfen werden können.

Neben der Kommunikation aus der Modellansicht gibt es noch einen weiteren Widerspruch zur Geschäftslogik in MVC. Viele Leute glauben, dass die gesamte Geschäftslogik ein Modell sein sollte (siehe dies SO Frage ), andererseits sagt der von Florian (in seiner Antwort) geteilte Link Geschäftslogik sollte auf Controller sein.

Abgesehen davon besteht die Möglichkeit, die Geschäftslogik in Anwendungslogik (auf Controller setzen) und Domänenanmeldung (auf Modell setzen) zu unterteilen.

Die Moral der Geschichte lautet also: MVC bedeutet, dass Modell, Ansicht und Controller getrennt sein sollten. Davon abgesehen, was auch immer am besten zu Ihnen passt.

1
Mohit Leekha

Ich stimme Paul Hegarty zu und glaube, dass die Ansicht nichts über das Modell wissen darf. Es ist nicht so schwer zu erreichen, aber es bringt zusätzliche Vorteile für Ihr Design und Ihre zukünftige Flexibilität.

In kleinen Anwendungen (normalerweise Desktop), in denen ich "Dummy" ViewModel-Klassen vermeiden und die Dinge einfach halten möchte, verwende ich auch die IModel-Oberfläche (siehe Antwort oben) und achte darauf, dass Model keine Ahnung von der Ansicht hat (Abonnenten verwenden) wie in der klassischen MVC).

Auch in diesem Fall ist der Controller so eingestellt, dass er ziemlich mit der Ansicht gekoppelt ist, und der Einfachheit halber trenne ich sie nicht immer klar voneinander.

Der zweite „vereinfachte“ Ansatz ist in Ordnung, wenn Sie möglicherweise mehrere Ansichten für dasselbe Modell haben. Ich würde ihn jedoch nicht empfehlen, wenn Sie dieselbe Ansicht für verschiedene Modelle verwenden möchten. Unter "anders" verstehe ich von Natur aus wirklich anders und nicht nur JUnit-Testklassen, die dem Hauptmodell "folgen".

1
Dime

Ich verwende DTO für die Kommunikation in der Modellansicht.

Zum Beispiel:

  • Benutzer füllt das Aktualisierungsformular aus (Ansicht)
  • Benutzer sendet Formular
  • Der Controller bindet Formulardaten an UserUpdateDTO
    • DTO und UserModel sind POJOs, aber DTO hat keine ID und keinen Benutzernamen, da wir den Benutzernamen nicht aktualisieren können.
    • Ein weiterer Unterschied besteht darin, dass die Modellklasse Beziehungen und Zuordnungen hat, DTO jedoch nur Daten speichert und möglicherweise JSR 303-Validatoren hinzufügt
  • Controller sagt es zur Serviceschicht, um zu speichern
  • Die Serviceschicht fordert die DAO-Schicht auf, die Daten beizubehalten
0
Fırat KÜÇÜK