Was ist eigentlich MVC?

Wie beantworten Sie als seriöser Programmierer die Frage Was ist MVC?

In meinen Augen ist MVC eine Art Nebelthema - und aus diesem Grund können Sie es, wenn Ihr Publikum ein Anfänger ist, 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, eine Richtung zu finden, die nicht die Reaktion "Nun, das stimmt nicht! ..." riskiert. Wir haben alle unterschiedliche Erfahrungen in der Praxis und ich habe nicht zweimal das gleiche MVC-Implementierungsmuster kennengelernt.

Insbesondere scheinen Meinungsverschiedenheiten in Bezug auf Strenge, Komponentendefinition, Teiletrennung (welches Teil passt wohin) usw. zu bestehen.

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

MVC ist eine Softwarearchitektur - die Struktur des Systems -, die die Domänen- / Anwendungs- / Geschäftslogik (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 zum Ändern des Status seiner Informationen reagieren und Beobachter in ereignisgesteuerten Systemen sogar benachrichtigen, wenn sich Informationen ändern. Dies kann eine Datenbank oder eine beliebige Anzahl von Datenstrukturen oder Speichersystemen sein. Kurz gesagt, es ist die Daten- und Datenverwaltung 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.

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

Insgesamt bilden diese drei Komponenten zusammen die drei Grundkomponenten von MVC.

Analogie

Ich erklärte meinem Vater MVC folgendermaßen:

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 die Steuerung und die Kamera die Ansicht .

Da die Box weder über die Kamera noch über den Fotografen Bescheid weiß , ist sie völlig unabhängig. Durch diese Trennung kann der Fotograf um die Box herumgehen und die Kamera in einem beliebigen Winkel ausrichten, um die gewünschte Aufnahme / Ansicht zu erhalten.

Nicht-MVC-Architekturen sind in der Regel eng miteinander integriert. Wenn die Box, der Controller und die Kamera ein und dasselbe Objekt wären, müssten wir jedes Mal die Box und die Kamera auseinanderbauen, wenn wir eine neue Ansicht erhalten möchten . Außerdem ist das Fotografieren immer so, als würde man versuchen, ein Selfie zu machen - und das ist nicht immer ganz einfach.

Ausführliche Erklärung

Erst nachdem ich die folgende Frage / Antwort gelesen hatte, hatte ich das Gefühl, MVC zu verstehen. Quote: 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.

MVC dreht sich alles um die Trennung von Bedenken.

Das Model ist verantwortlich für die Verwaltung der Programmdaten (sowohl der privaten als auch der Kundendaten). Der View / Controller ist dafür verantwortlich, der Außenwelt die Möglichkeit zu geben, mit den Kundendaten 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 verfügt über eine externe Schnittstelle (GUI / CLI / Webformular / High-Level-IPC / usw.), über die das gesamte Programm mit ihm kommunizieren kann.

Das Model ist für die Aufrechterhaltung der Integrität der Programmdaten verantwortlich. Wenn diese beschädigt werden, ist das Spiel für alle vorbei. Der View / Controller ist dafür verantwortlich, die Integrität der Benutzeroberfläche aufrechtzuerhalten, sicherzustellen, dass alle Textansichten aktuelle Werte anzeigen, 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 Auslegen von Dialogfeldern oder zum Empfangen von Benutzereingaben. Die Ansicht / Steuerung enthält keinen Modellcode. Kein Code zum Überprüfen von URLs oder zum 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 wahren 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 damit zu interagieren, aber solange man die entsprechenden Modell-API-Beschwörungen kennt, speichert und bearbeitet das Programm die Daten wie gewohnt.

Warum ist das möglich? Nun, die einfache Antwort ist, dass dies alles dank der geringen Kopplung zwischen der Model- und der View / Controller-Ebene möglich ist. Dies ist jedoch nicht die ganze Geschichte. Entscheidend für das gesamte MVC-Muster ist die Richtung, in die diese Verbindung verläuft: ALLE Anweisungen fließen von der Ansicht / Steuerung zum Modell. Das Modell teilt dem View / Controller NIEMALS mit, was zu tun ist.

Warum? Denn in MVC darf der View / Controller zwar etwas ü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 um eine klare Trennung der Anliegen.

Warum? Damit die Komplexität des Programms nicht außer Kontrolle gerät und Sie, den Entwickler, nicht darunter leiden. Je größer das Programm ist, desto größer ist die Anzahl der Komponenten in diesem Programm. Und je mehr Verbindungen zwischen diesen Komponenten bestehen, desto schwieriger ist es für Entwickler, einzelne Komponenten zu warten, zu erweitern oder zu ersetzen oder sogar 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 die Wiege einer Katze sehen? Das MVC-Muster vermeidet letzteres, indem kreisförmige Verbindungen nicht zugelassen werden: 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 'Einweg'-Beschränkung bemerken: Wie kann das Modell die Ansicht / Steuerung über Änderungen der Benutzerdaten des Modells informieren, wenn das Modell dies nicht einmal darf? Weißt du, dass der View / Controller egal Nachrichten an ihn sendet? Aber keine Sorge: Es gibt eine Lösung dafür, und sie ist ziemlich ordentlich, auch wenn es auf den ersten Blick ein bisschen umständlich zu sein scheint. 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 auszuführen) und 2. das Modell anweisen, ihm Dinge zu geben (Daten zurückzugeben). Die Ansichts- / Controller-Ebene überträgt Anweisungen an die Modellebene und ruft Informationen aus der Modellebene ab.

Und das ist , wo Sie Ihr erstes MyCoolListControl Beispiel schief geht, weil die API für diese Klasse erfordert , dass Informationen werden geschoben hinein, so dass Sie wieder eine Zwei-Wege - Kopplung zwischen den Schichten zu haben, die MVC - Regeln zu verletzen und Sie gleich wieder in die Dumping Die Wiegenarchitektur der Katze, die Sie [vermutlich] vermeiden wollten.

Stattdessen sollte die MyCoolListControl-Klasse dem Ablauf folgen und die benötigten Daten aus der darunter liegenden Ebene abrufen, wenn sie benötigt werden. Bei einem Listen-Widget bedeutet dies im Allgemeinen, dass Sie nach der Anzahl der Werte und anschließend nach jedem dieser Elemente fragen, da dies der einfachste und lockerste Weg ist, um die Kopplung auf ein Minimum zu beschränken. Und wenn das Widget diese Werte beispielsweise dem Benutzer in einer guten alphabetischen Reihenfolge präsentieren möchte, ist dies seine Berechtigung. und seine Verantwortung natürlich.

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

Hier ist das Problem: Viele Ansichtsobjekte sind statusbehaftet, z. B. kann ein Kontrollkästchen 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 für Anzeigezwecke gespeichert werden (der Status des Kontrollkästchens, der aktuelle 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 Model nicht einmal, der Ansicht eine Nachricht zu senden, die besagt, dass sich sein Status geändert hat.

Naja fast. Okay, die Model-Ebene darf nicht direkt mit anderen Ebenen kommunizieren, da dies voraussetzt, dass sie etwas über diese Ebenen weiß, 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?

Wie Sie sehen, besteht die Antwort darin, ein Benachrichtigungssystem einzurichten, das der Model-Ebene einen Ort bietet, an dem sie insbesondere niemandem mitteilen kann, dass sie gerade etwas Interessantes getan hat. Andere Ebenen können dann Listener mit diesem Benachrichtigungssystem veröffentlichen, um auf die Ankündigungen zu warten, an denen sie tatsächlich interessiert sind. Die Model-Ebene muss nichts darüber wissen, wer zuhört (oder auch, wenn überhaupt jemand zuhört!). Es wird nur eine Ankündigung gepostet und diese dann vergessen. Und wenn jemand diese Ansage hört und danach Lust hat, etwas zu tun - wie das Model 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 jemand anderes mit diesem Wissen macht, liegt bei ihnen.

MVC bleibt erhalten und alle sind glücklich. Ihr Anwendungsframework bietet möglicherweise ein integriertes Benachrichtigungssystem. Wenn nicht, können Sie auch ein eigenes schreiben (siehe 'Beobachtermuster').

...

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

Prost,

hat

MVC ist meist ein Schlagwort.

Früher galt es als Muster, aber seine ursprüngliche Definition von 1979 wurde verworfen, weitergegeben, falsch interpretiert und aus dem ursprünglichen Kontext herausgenommen. Es wurde bis zu dem Punkt falsch definiert, an dem es einer Religion ähnelt, und während dies sicherlich den Frachtkultisten hilft, es zu verteidigen, ist sein Name nicht mehr mit einer Reihe von Richtlinien verbunden . Als solches kann es nicht mehr als Muster angesehen 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 zu. 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 der Tatsache , dass Semi-Analphabeten-Programmierer als Zielgruppe fungieren, eine wirklich schlechte Publizität für Softwaremuster im Allgemeinen schafft.

MVC wurde somit zu einer Trennung von Anliegen, die für Leute bestimmt sind, die nicht wirklich zu viel darüber nachdenken wollen.

• Das Datenmodell wird in einer Richtung gehandhabt,
• der blick in einen anderen,
• Der Rest wird nur als "Controller" bezeichnet und liegt im Ermessen des Lesers.

Websites / Webanwendungen haben in den 90er Jahren die Trennung von Bedenken nicht wirklich angewendet.

Es waren schreckliche Päckchen mit gemischtem Spaghetti-Code.
UI-Änderungen, Redesigns und Datenumstellungen waren unglaublich schwierig, teuer, langwierig, bedrückend und unglückselig.

Webtechnologien wie ASP, JSP und PHP machen es zu einfach, Bedenken in Bezug auf Anzeigen mit Daten und Bedenken in Bezug auf Anwendungen zu vermischen . Neulinge auf dem Gebiet stoßen normalerweise untrennbare Code-Mudballs aus, wie in alten Zeiten.

So begann eine wachsende Anzahl von Leuten, "use MVC" in Endlosschleifen in Supportforen zu wiederholen . Die Zahl der Leute stieg bis hin zu Managern und Marketingfachleuten (zu einigen war der Begriff bereits aus Zeiten der GUI-Programmierung bekannt, in denen das Muster Sinn machte) .

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 machen , nicht als Heilmittel gegen Krebs .

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 im Allgemeinen 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 (ziemlich uninteressant), oder es kann eine Objektstruktur sein ...

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

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

ANSICHTEN

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

Eine Ansicht wird an ihr Modell (oder Modellteil) angehängt und bezieht 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. (Möglicherweise werden Sie nach der ID des Modells gefragt und es wird eine Instanz von Text erwartet. Möglicherweise wird nicht davon ausgegangen, dass das Modell der Klasse Text angehört.)

STEUERGERÄTE

Ein Controller ist die Verbindung zwischen einem Benutzer und dem System. Der Benutzer erhält Eingaben, indem relevante Ansichten an geeigneten Stellen auf dem Bildschirm angezeigt werden. Es stellt Mittel zur Benutzerausgabe bereit, indem dem Benutzer Menüs oder andere Mittel zum Geben von Befehlen und Daten präsentiert werden. Die Steuerung 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 verbinden, indem er Pfeile zwischen ihnen zeichnet.

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

HERAUSGEBER

Ein Controller ist mit all seinen Ansichten verbunden, sie werden Teile des Controllers genannt. Einige Ansichten verfügen über einen speziellen Controller, einen Editor , mit dem der Benutzer die Informationen ändern kann, die in der Ansicht angezeigt werden. Solche Editoren können in den Pfad zwischen dem Controller und seiner Ansicht eingefügt werden und dienen als Erweiterung des Controllers. Sobald der Bearbeitungsvorgang abgeschlossen ist, wird der Editor aus dem Pfad entfernt und verworfen.

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

MVC ist ein Entwurfsmuster, das zum Isolieren der Geschäftslogik von der Präsentation verwendet wird.

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

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

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 zur Änderung oder zum Zugriff enthalten.
2. Ansicht - Eine Interpretation der Daten (Modell). Dies ist nur auf eine visuelle Darstellung beschränkt, es kann sich jedoch auch um Audioinformationen, abgeleitete Informationen (z. B. Statistiken, die in ein anderes Modellobjekt geleitet werden) usw. handeln. Außerdem kann ein einzelnes Modell mehrere Ansichten haben.
3. Steuerung - Steuert externe Eingaben an das System und ruft Änderungen am Modell auf. Die Steuerung / 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 von der Ansicht völlig unabhängig sind.

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

Ich denke, dieser Artikel ist es wert, gelesen zu werden. GUI-Architekturen von Martin Fowler

Zunächst müssen Sie feststellen, wer der Fragesteller ist und welche Art von Antwort er sucht. Sie antworten auf diese Frage mit einer anderen Frage wie "In welchem ​​Sinne?"

Sie können fragen, ob sie sich auf MVC im Allgemeinen beziehen, auf 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 Aspekte getrennt werden, um wartbarere Software zu ermöglichen.

Du kannst auch sagen:

Durch die Trennung der Ansicht vom Controller vom Modell wird die Isolierung von Komponenten aufgrund ihrer Zuständigkeiten gefördert. In der Theorie und 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 beurteilt, ob Sie die Antwort geben, die sie erwarten. Die einzige Lösung für das Problem ist herauszufinden, welche Art von Antwort sie erwarten.

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

Jetzt muss die Ansicht offensichtlich irgendwann auf dem Bildschirm platziert werden. Wie sollte das geschehen? Dein CONTROLLER , in Android Activity genannt. Wie der Name schon sagt, hat Aktivität etwas mit Aktivität zu tun. Selbst wenn der einzige Zweck darin besteht, die in Schritt 1 definierte Ansicht anzuzeigen, wird eine Aktion ausgeführt. Daher ruft die Aktivität 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) konnten das Layout der Ansicht mehrmals ändern, ohne auch nur eine Codezeile in unserer Aktivität zu ändern.

Jetzt macht es nicht viel Sinn, Ihr schönes, glänzendes und 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 sie die Daten vom Benutzer übernimmt und an eine andere Person weitergibt, um sie zu verarbeiten (verarbeiten, speichern, löschen). An wen wird es weitergegeben? Na ja, zu einem MODELL . Ich stelle mir ein Modell gerne als reines Modell vor. Java- Klasse, die nichts über den Anwendungskontext weiß, in dem sie lebt (in der Praxis wird dies so gut wie nie der Fall sein).

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. In meiner Aktivität werden die drei Werte aus der Benutzereingabe übernommen, ein neues Personenobjekt erstellt und eine Methode aufgerufen, die weiß, wie mit einer personenspezifischen Logik umgegangen wird. Hier hast du es. Model View Controller.

Ich beginne immer damit, ihnen zu sagen, dass das Muster nichts Neues ist und es schon viele Jahre gibt ... an diesem Punkt geben sie mir einen neugierigen Blick und BAM !, sie sind begeistert:

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