it-swarm-eu.dev

Was ist MVC wirklich?

Wie beantworten Sie als ernsthafter Programmierer die Frage Was ist MVC?

In meinen Augen ist MVC eine Art nebulöses Thema - und wenn Ihr Publikum ein Lernender ist, können Sie es daher in allgemeinen Begriffen beschreiben, die wahrscheinlich nicht kontrovers sind.

Wenn Sie jedoch mit einem sachkundigen Publikum, insbesondere einem Interviewer, sprechen, fällt es mir schwer, über eine Richtung nachzudenken, die keine Reaktion von "Nun, das ist nicht richtig! ..." riskiert. Wir haben alle unterschiedliche Erfahrungen in der Praxis, und ich habe nicht zweimal dasselbe MVC-Implementierungsmuster getroffen.

Insbesondere scheint es Meinungsverschiedenheiten hinsichtlich der Strenge, der Komponentendefinition, der Trennung von Teilen (welches Teil passt wohin) usw. zu geben.

Also, wie soll ich MVC erklären auf eine Weise, die korrekt, präzise und unumstritten ist?

206
Nicole

MVC ist eine Softwarearchitektur - die Struktur des Systems -, die die Logik von Domäne/Anwendung/Geschäft (was auch immer Sie bevorzugen) vom Rest der Benutzeroberfläche trennt. Dazu wird die Anwendung in drei Teile unterteilt: das Modell, die Ansicht und den Controller.

Das Modell verwaltet grundlegende Verhaltensweisen und Daten der Anwendung. Es kann auf Informationsanfragen reagieren, auf Anweisungen reagieren, um den Status seiner Informationen zu ändern, und sogar Beobachter in ereignisgesteuerten Systemen benachrichtigen, wenn sich Informationen ändern. Dies kann eine Datenbank oder eine beliebige Anzahl von Datenstrukturen oder Speichersystemen sein. Kurz gesagt, es sind die Daten und das Datenmanagement der Anwendung.

Die Ansicht stellt effektiv das Benutzeroberflächenelement der Anwendung bereit. Es werden Daten aus dem Modell in ein Formular gerendert, das für die Benutzeroberfläche geeignet ist.

Die Steuerung empfängt Benutzereingaben und ruft Modellobjekte und die Ansicht auf, um entsprechende Aktionen auszuführen.

Insgesamt arbeiten diese drei Komponenten zusammen, um die drei Grundkomponenten von MVC zu erstellen.

158
Bob

Analogie

Ich habe meinem Vater MVC folgendermaßen erklärt:

MVC (Model, View, Controller) ist ein Muster zum Organisieren von Code in einer Anwendung, um die Wartbarkeit zu verbessern.

Stellen Sie sich einen Fotografen mit seiner Kamera in einem Studio vor. Ein Kunde bittet ihn, ein Foto von einer Schachtel zu machen.

Die Box ist das Modell, der Fotograf ist der Controller und die Kamera ist die Ansicht.

Da die Box nicht weiß über die Kamera oder den Fotografen weiß, ist sie völlig unabhängig. Diese Trennung ermöglicht es dem Fotografen, um die Box herumzugehen und die Kamera in einen beliebigen Winkel zu richten, um die gewünschte Aufnahme/Ansicht zu erhalten.

Nicht-MVC-Architekturen sind in der Regel eng miteinander verbunden. Wenn die Box, der Controller und die Kamera ein und dasselbe Objekt wären, müssten wir jedes Mal die Box und der Kamera auseinander ziehen und neu bauen wollte eine neue Ansicht bekommen. Außerdem wäre das Fotografieren immer wie der Versuch, ein Selfie zu machen - und das ist nicht immer sehr einfach.


Detaillierte Erklärung

Erst nachdem ich die folgende Frage/Antwort der Mailliste gelesen hatte, hatte ich das Gefühl, MVC zu verstehen. Zitat: https://mail.python.org/pipermail/python-list/2006-January/394968.html

bwaha schrieb:

Der Autor verweist auf mvctree.py in wxPython als Beispiel für das MVC-Design. Ich bin jedoch immer noch zu grün, daher finde ich dieses Beispiel zu komplex und verstehe die vom Autor empfohlene Trennung nicht.

Bei MVC dreht sich alles um die Trennung von Bedenken.

Das Modell ist für die Verwaltung der Programmdaten (sowohl Privat- als auch Kundendaten) verantwortlich. Der View/Controller ist dafür verantwortlich, der Außenwelt die Möglichkeit zu geben, mit den Client-Daten des Programms zu interagieren.

Das Modell bietet eine interne Schnittstelle (API), über die andere Teile des Programms mit ihm interagieren können. Der View/Controller bietet eine externe Schnittstelle (GUI/CLI/Webformular/High-Level-IPC/etc.), Damit alles außerhalb des Programms mit ihm kommunizieren kann.

Das Modell ist für die Aufrechterhaltung der Integrität der Programmdaten verantwortlich, denn wenn diese beschädigt werden, ist das Spiel für alle vorbei. Die Ansicht/Steuerung ist dafür verantwortlich, die Integrität der Benutzeroberfläche aufrechtzuerhalten, sicherzustellen, dass in allen Textansichten aktuelle Werte angezeigt werden, Menüelemente zu deaktivieren, die nicht für den aktuellen Fokus gelten usw.

Das Modell enthält keinen View/Controller-Code. Keine GUI-Widget-Klassen, kein Code zum Anordnen von Dialogfeldern oder zum Empfangen von Benutzereingaben. Die Ansicht/Steuerung enthält keinen Modellcode. Kein Code zum Überprüfen von URLs oder Ausführen von SQL-Abfragen und auch kein ursprünglicher Status: Alle von Widgets gespeicherten Daten dienen nur zu Anzeigezwecken und spiegeln lediglich die im Modell gespeicherten tatsächlichen Daten wider.

Hier ist der Test eines echten MVC-Designs: Das Programm sollte im Wesentlichen auch ohne angeschlossenen View/Controller voll funktionsfähig sein. OK, die Außenwelt wird Probleme haben, in dieser Form mit ihr zu interagieren, aber solange man die entsprechenden Beschwörungsformeln für die Modell-API kennt, wird das Programm Daten wie gewohnt speichern und bearbeiten.

Warum ist das möglich? Die einfache Antwort lautet, dass dies alles auf die geringe Kopplung zwischen den Ebenen Model und View/Controller zurückzuführen ist. Dies ist jedoch nicht die ganze Geschichte. Was für das gesamte MVC-Muster entscheidend ist, ist die Richtung, in die diese Verbindung geht: ALLE Anweisungen fließen von der Ansicht/Steuerung bis das Modell. Das Modell teilt dem View/Controller NIEMALS mit, was zu tun ist.

Warum? Denn in MVC darf der View/Controller zwar ein wenig über das Modell (insbesondere die API des Modells) wissen, aber das Modell darf überhaupt nichts über den View/Controller wissen.

Warum? Denn bei MVC geht es darum, eine klare Trennung der Bedenken zu erreichen.

Warum? Um zu verhindern, dass die Programmkomplexität außer Kontrolle gerät und Sie, den Entwickler, darunter begraben. Je größer das Programm ist, desto mehr Komponenten befinden sich in diesem Programm. Und je mehr Verbindungen zwischen diesen Komponenten bestehen, desto schwieriger ist es für Entwickler, einzelne Komponenten zu warten/zu erweitern/zu ersetzen oder einfach nur zu verfolgen, wie das gesamte System funktioniert. Fragen Sie sich Folgendes: Wenn Sie sich ein Diagramm der Programmstruktur ansehen, möchten Sie lieber einen Baum oder eine Wiege einer Katze sehen? Das MVC-Muster vermeidet letzteres, indem es Kreisverbindungen nicht zulässt: B kann eine Verbindung zu A herstellen, A kann jedoch keine Verbindung zu B herstellen. In diesem Fall ist A das Modell und B die Ansicht/Steuerung.

Übrigens, wenn Sie scharf sind, werden Sie ein Problem mit der soeben beschriebenen Einwegbeschränkung bemerken: Wie kann das Modell die Ansicht/den Controller über Änderungen in den Benutzerdaten des Modells informieren, wenn das Modell dies nicht einmal darf? Wissen Sie, dass der View/Controller, egal, Nachrichten an ihn senden? Aber keine Sorge: Es gibt eine Lösung dafür, und es ist ziemlich ordentlich, auch wenn es auf den ersten Blick ein bisschen umständlich erscheint. Wir werden gleich darauf zurückkommen.

In der Praxis kann ein View/Controller-Objekt dann über die API des Modells 1. das Modell anweisen, Dinge zu tun (Befehle ausführen), und 2. das Modell anweisen, ihm Dinge zu geben (Daten zurückgeben). Die Ansichts-/Controller-Ebene schiebt Anweisungen In die Modellebene und ruft Informationen ab aus der Modellebene.

Und hier geht Ihr erstes MyCoolListControl-Beispiel schief, da die API für diese Klasse erfordert, dass Informationen gepusht enthalten sind, sodass Sie wieder eine bidirektionale Kopplung zwischen Ebenen haben und die MVC regiert und bringt Sie direkt zurück in die Wiegenarchitektur der Katze, die Sie [vermutlich] zunächst vermeiden wollten.

Stattdessen sollte die MyCoolListControl-Klasse mit dem Flow gehen und die benötigten Daten aus der darunter liegenden Ebene abrufen, wenn sie benötigt werden. Im Fall eines Listen-Widgets bedeutet dies im Allgemeinen, zu fragen, wie viele Werte es gibt, und dann nacheinander nach jedem dieser Elemente zu fragen, da dies der einfachste und lockerste Weg ist, dies zu tun, und daher die Kopplung auf ein Minimum beschränkt. Und wenn das Widget dem Benutzer diese Werte beispielsweise in einer schönen alphabetischen Reihenfolge präsentieren möchte, ist dies seine Berechtigung. und natürlich seine Verantwortung.

Nun ein letztes Rätsel, wie ich bereits angedeutet habe: Wie können Sie die Anzeige der Benutzeroberfläche mit dem Status des Modells in einem MVC-basierten System synchronisieren?

Hier ist das Problem: Viele View-Objekte sind statusbehaftet, z. Ein Kontrollkästchen kann aktiviert oder deaktiviert sein. Ein Textfeld kann bearbeitbaren Text enthalten. MVC schreibt jedoch vor, dass alle Benutzerdaten in der Modellebene gespeichert werden. Daher müssen alle Daten, die von anderen Ebenen zu Anzeigezwecken gespeichert werden (Status des Kontrollkästchens, aktueller Text des Textfelds), eine untergeordnete Kopie dieser primären Modelldaten sein. Wenn sich der Status des Modells ändert, ist die Kopie dieses Status in der Ansicht nicht mehr korrekt und muss aktualisiert werden.

Aber wie? Das MVC-Muster verhindert, dass das Modell eine neue Kopie dieser Informationen in die Ansichtsebene überträgt. Heck, es erlaubt dem Modell nicht einmal, der Ansicht eine Nachricht zu senden, um zu sagen, dass sich sein Status geändert hat.

Naja fast. Okay, die Modellebene darf nicht direkt mit anderen Ebenen kommunizieren, da sie dazu etwas über diese Ebenen wissen müsste, und MVC-Regeln verhindern dies. Wenn jedoch ein Baum in einen Wald fällt und niemand da ist, um ihn zu hören, macht er dann ein Geräusch?

Sie sehen, die Antwort besteht darin, ein Benachrichtigungssystem einzurichten, das der Modellebene einen Ort bietet, an dem sie niemandem mitteilen kann, dass sie gerade etwas Interessantes getan hat. Andere Ebenen können dann Listener mit diesem Benachrichtigungssystem posten, um auf die Ankündigungen zu warten, an denen sie tatsächlich interessiert sind. Die Modellebene muss nichts darüber wissen, wer zuhört (oder auch wenn überhaupt jemand zuhört!). es postet nur eine Ankündigung und vergisst sie dann. Und wenn jemand diese Ankündigung hört und Lust hat, danach etwas zu tun - wie das Modell nach neuen Daten zu fragen, damit es seine Bildschirmanzeige aktualisieren kann - dann großartig. Das Modell listet nur auf, welche Benachrichtigungen es als Teil seiner API-Definition sendet. und was jeder andere mit diesem Wissen macht, liegt bei ihm.

MVC bleibt erhalten und alle sind glücklich. Ihr Anwendungsframework bietet möglicherweise ein integriertes Benachrichtigungssystem, oder Sie können Ihr eigenes Benachrichtigungssystem schreiben, wenn dies nicht der Fall ist (siehe 'Beobachtermuster').

...

Wie auch immer, hoffe das hilft. Sobald Sie die Beweggründe hinter MVC verstanden haben, machen die Gründe, warum Dinge so gemacht werden, wie sie sind, Sinn, auch wenn sie auf den ersten Blick komplexer als nötig erscheinen.

Prost,

hat

138
JW01

MVC ist meistens ein Schlagwort.

Früher galt es als Muster, aber seine ursprüngliche Definition von 1979 wurde niedergeschlagen, weitergegeben, falsch interpretiert und aus dem ursprünglichen Kontext herausgenommen. Es wurde bis zu dem Punkt schlecht neu definiert, an dem es anfängt, einer Religion zu ähneln, und während dies sicherlich seinen Frachtkultisten hilft, es zu verteidigen, sein Name ist nicht mehr mit einem soliden Satz von Richtlinien verbunden. Als solches kann es nicht mehr wirklich als Muster betrachtet werden.

MVC sollte niemals Webanwendungen beschreiben.
Weder moderne Betriebssysteme noch Sprachen.
(Einige von ihnen haben die Definition von 1979 tatsächlich überflüssig gemacht)

Es wurde gemacht, um. Und es hat nicht geklappt.

Wir haben es jetzt mit einem obszönen Web-MVC-Hybrid zu tun, der mit seinem schrecklichen Schlagwortstatus, seiner schlechten Definition und seiner Semi-Analphabeten-Programmierer als Ziel dient demografisch, macht eine wirklich schlechte Werbung für Softwaremuster im Allgemeinen.

MVC wurde somit zu einer Trennung von Bedenken für Menschen, die nicht wirklich zu viel darüber nachdenken wollen.

  • Das Modell Daten wird in eine Richtung behandelt.
  • das view in einem anderen,
  • der Rest heißt nur "controller" und liegt im Ermessen des Lesers.

Websites/Webanwendungen wurden in den 90er Jahren nicht wirklich verwendet, um die Trennung von Bedenken anzuwenden.

Es waren schreckliche Pfuschereien mit gemischtem Spaghetti-Code.
Änderungen, Neugestaltungen und Neuanordnungen der Benutzeroberfläche waren unglaublich schwierig, teuer, lang, deprimierend und unglücklich.

Webtechnologien wie ASP, JSP und PHP machen es zu einfach zu mischen zeigen Bedenken hinsichtlich Daten und Anwendungsbedenken an. Neulinge auf dem Gebiet geben normalerweise untrennbare Code-Schlammbälle wie in aus diese alten Zeiten.

Daher wiederholte eine wachsende Anzahl von Personen "use MVC" in Endlosschleifen in Support-Foren. Die Anzahl der Personen stieg so weit an, dass Manager und Vermarkter einbezogen wurden (zu einigen war der Begriff bereits aus jener Zeit in der GUI-Programmierung bekannt, in der das Muster Sinn machte), und dies wurde zum Giganten eines Schlagworts, dem wir uns jetzt stellen müssen .

So wie es aussieht, ist es gesunder Menschenverstand , keine Methodik .
Es ist ein Ausgangspunkt , keine Lösung .
Es ist, als würde man den Leuten sagen, sie sollen Luft atmen oder knirschen , nicht a Heilung für Krebs.

87
ZJR

Der beste Weg, es zu definieren, ist, zu den Originalschriften von Trygve Reenskaug zu gehen, der es erfunden hat: http://heim.ifi.uio.no/~trygver/themes/mvc /mvc-index.html

Insbesondere dieses Papier wird allgemein als Definitionstext betrachtet: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

MODELLE

Modelle repräsentieren Wissen. Ein Modell kann ein einzelnes Objekt sein (eher uninteressant), oder es kann eine Struktur von Objekten sein ...

Es sollte eine Eins-zu-Eins-Entsprechung zwischen dem Modell und seinen Teilen einerseits und der vom Eigentümer des Modells wahrgenommenen dargestellten Welt andererseits bestehen. Die Knoten eines Modells sollten daher einen identifizierbaren Teil des Problems darstellen.

Die Knoten eines Modells sollten sich alle auf derselben Problemstufe befinden. Es ist verwirrend und wird als schlechte Form angesehen, problemorientierte Knoten (z. B. Kalendertermine) mit Implementierungsdetails (z. B. Absätzen) zu mischen.

ANSICHTEN

Eine Ansicht ist eine (visuelle) Darstellung ihres Modells. Normalerweise werden bestimmte Attribute des Modells hervorgehoben und andere unterdrückt. Es fungiert somit als Präsentationsfilter .

Eine Ansicht wird an ihr Modell (oder Modellteil) angehängt und erhält die für die Präsentation erforderlichen Daten aus dem Modell, indem Fragen gestellt werden. Es kann auch das Modell aktualisieren, indem entsprechende Nachrichten gesendet werden. Alle diese Fragen und Nachrichten müssen in der Terminologie des Modells enthalten sein. Die Ansicht muss daher die Semantik der Attribute des Modells kennen, das sie darstellt. (Es kann beispielsweise nach der Kennung des Modells fragen und eine Instanz von Text erwarten. Es kann jedoch nicht davon ausgegangen werden, dass das Modell der Klasse Text entspricht.)

CONTROLLER

Ein Controller ist die Verbindung zwischen einem Benutzer und dem System. Es bietet dem Benutzer Eingaben, indem relevante Ansichten an geeigneten Stellen auf dem Bildschirm angezeigt werden. Es bietet Mittel zur Benutzerausgabe, indem dem Benutzer Menüs oder andere Mittel zum Geben von Befehlen und Daten angezeigt werden. Der Controller empfängt eine solche Benutzerausgabe, übersetzt sie in die entsprechenden Nachrichten und leitet diese Nachrichten an eine oder mehrere der Ansichten weiter.

Ein Controller sollte niemals die Ansichten ergänzen, er sollte beispielsweise niemals die Ansichten von Knoten durch Zeichnen von Pfeilen zwischen ihnen verbinden.

Umgekehrt sollte eine Ansicht niemals Informationen über Benutzereingaben wie Mausoperationen und Tastenanschläge erhalten. Es sollte immer möglich sein, eine Methode in eine Steuerung zu schreiben, die Nachrichten an Ansichten sendet, die eine beliebige Folge von Benutzerbefehlen genau wiedergeben.

HERAUSGEBER

Ein Controller ist mit allen seinen Ansichten verbunden. Sie werden als Teile des Controllers bezeichnet. Einige Ansichten bieten einen speziellen Controller, einen Editor , mit dem der Benutzer die von der Ansicht angezeigten Informationen ändern kann. Solche Editoren können in den Pfad zwischen der Steuerung und ihrer Ansicht eingebunden werden und dienen als Erweiterung der Steuerung. Sobald der Bearbeitungsvorgang abgeschlossen ist, wird der Editor aus dem Pfad entfernt und verworfen.

Beachten Sie, dass ein Editor über die Metaphern der verbundenen Ansicht mit dem Benutzer kommuniziert. Der Editor ist daher eng mit der Ansicht verbunden. Ein Controller erhält einen Editor, indem er ihn nach der Ansicht fragt - es gibt keine andere geeignete Quelle.

39
Larry OBrien

MVC ist ein Entwurfsmuster, mit dem Geschäftslogik von der Präsentation isoliert wird.

Es unterscheidet sich von vielen anderen Entwurfsmustern dadurch, dass es normalerweise nicht prägnant implementiert wird, sondern die Basis eines Frameworks ist.

Während eine Anwendung, die ein Strategiemuster implementiert, nur ein kleines Detail darüber ist, die Aussage, dass eine Webanwendung das MVC-Entwurfsmuster verwendet, definiert ihre Architektur sehr stark.

11
Boris Yankov

MVC ist ein Software-Design, das die folgenden Komponenten eines Systems oder Subsystems trennt:

  1. Modell - Daten zum Status der Anwendung oder ihrer Komponenten. Kann Routinen zum Ändern oder Zugreifen enthalten.
  2. Ansicht - Eine Interpretation der Daten (Modell). Dies ist nur auf eine visuelle Darstellung beschränkt, kann jedoch Audio, abgeleitete Informationen (z. B. Statistiken, die in ein anderes Modellobjekt geleitet werden) usw. sein. Darüber hinaus kann ein einzelnes Modell mehrere Ansichten haben.
  3. Steuerung - Verarbeitet externe Eingaben in das System und ruft Änderungen am Modell auf. Das Steuerelement/die Ansicht kann eng miteinander verbunden sein (im Fall einer Benutzeroberfläche). Es können jedoch auch andere externe Eingaben (z. B. Netzwerkbefehle) verarbeitet werden, die völlig unabhängig von der Ansicht sind.
8
lorean

Ich würde sagen, MVC ist ein Konzept oder eine Familie ähnlicher Muster.

Ich denke, dieser Artikel ist lesenswert. GUI-Architekturen von Martin Fowler

6
franziga

Zunächst müssen Sie feststellen, wer der Fragesteller ist und nach welcher Antwort er sucht. Sie beantworten diese Frage mit einer anderen Frage, z. B. "In welchem ​​Sinne?"

Sie können fragen, ob sie sich allgemein auf MVC beziehen, eine bestimmte Implementierung von MVC (dh asp.net MVC, Spring MVC, Smalltalk MVC usw.), was es technisch ist, was es philisophisch ist (ja, es hat eine Philosophie auch), etc ..

Wenn dies eine Frage zu einem Test ist und Sie den Fragesteller nicht um Klärung bitten können, müssen Sie anhand des Kontexts raten.

Eine gute, einfache Antwort lautet:

MVC ist eine Software-Benutzeroberflächenarchitektur, mit der strukturelle und verhaltensbezogene Probleme getrennt werden, um eine wartbarere Software zu ermöglichen.

Du kannst auch sagen:

Durch die Trennung der Ansicht vom Controller vom Modell wird die Isolierung von Komponenten anhand ihrer Verantwortlichkeiten gefördert. In der Theorie und normalerweise in der Praxis trägt dies zur Verbesserung der Wartbarkeit bei, indem verhindert wird, dass sich die verschiedenen Teile des Systems vermischen und komplexere Systeme entstehen.

Aber am Ende werden Sie danach beurteilt, ob Sie die Antwort geben, die sie erwarten. Die einzige Lösung für das Problem besteht darin, herauszufinden, welche Art von Antwort sie erwarten.

3

Hier ist, was ich dazu sagen würde. Ich würde versuchen, es mit mobilen Anwendungen zu erklären, weil es das ist, mit dem ich am besten vertraut bin, und weil ich glaube, dass ich es nicht vollständig verstanden habe, bevor ich mit mobilen Anwendungen angefangen habe.
Nehmen wir zum Beispiel Android).
Präsentationsschicht, dh. Die Benutzeroberfläche kann (sollte, wird meistens) vollständig in XML angegeben werden. Nehmen wir zur Vereinfachung an, eine XML-Datei beschreibt einen Bildschirm in der Anwendung. XML-Datei spezifiziert Steuerelemente, Layout der Steuerelemente, Positionierung, Farben, Größe, Zeichenfolgenbeschriftungen ... alles in Bezug auf die Präsentation. Es weiß jedoch nichts darüber, wann es aufgerufen wird und wann es auf dem Bildschirm angezeigt wird. Wird es ein eigenständiges Layout oder ein Teil eines größeren Layouts sein? Da haben Sie es: Ihre perfekte ANSICHT .

Jetzt muss die Ansicht offensichtlich irgendwann auf dem Bildschirm platziert werden. Wie sollte das geschehen? Ihr CONTROLLER , in Android heißt Aktivität. Wie der Name schon sagt, führt Aktivität eine Aktivität aus. Auch wenn ihr einziger Zweck darin besteht Um die in Schritt 1 definierte Ansicht anzuzeigen, wird eine Aktion ausgeführt. Die Aktivität ruft eine Ansicht ab und zeigt sie auf dem Bildschirm an. Da die Ansicht nichts über die Aktivität weiß, weiß die Aktivität auch nichts über die tatsächliche Präsentation. Wir (die Programmierer) könnten dies Ordnen Sie das Layout der Ansicht mehrmals neu an, ohne auch nur eine Codezeile in unserer Aktivität zu ändern.

Jetzt macht es nicht viel Sinn, Ihr schönes, glänzendes, gut definiertes XML-Layout zu präsentieren, ohne etwas zu tun. Angenommen, wir möchten die vom Benutzer eingegebenen Daten speichern. Die Aktivität muss diesen Prozess angehen, indem die Daten vom Benutzer übernommen und an eine andere Person weitergegeben werden, um sie zu verarbeiten (verarbeiten, speichern, löschen). An wen wird es weitergegeben? Nun, zu einem MODELL . Ich stelle mir ein Modell gerne als eine reine Java - Klasse vor, die nichts über den Anwendungskontext weiß, in dem es lebt. (In der Praxis wird dies fast nie der sein Fall).

Angenommen, ich habe eine Klasse Person mit drei Eigenschaften: Name, Adresse, Alter. Mein XML-definiertes Layout enthält 3 Felder für Benutzereingaben: Name, Adresse, Alter. Meine Aktivität übernimmt die drei Werte aus Benutzereingaben, erstellt ein neues Personenobjekt und ruft eine Methode auf, die weiß, wie mit einer personenbezogenen Logik umzugehen ist. Hier hast du es. Model View Controller.

2
Maggie

Ich beginne immer damit, ihnen zu sagen, dass das Muster nichts Neues ist und es schon seit vielen Jahren gibt ... an diesem Punkt sehen sie mich neugierig an und BAM!, Sie sind begeistert:

Und dann würde ich so ziemlich über die verschiedenen Punkte wie die vorherigen Antworten sprechen, aber ich denke, es ist wichtig, auch kontextbezogen zu sein, wie JB King sagte, ASP.NET MVC usw.

1
Dal