Ich habe viele Veröffentlichungen über MVC gelesen, aber ich kann immer noch nicht klar verstehen, warum wir "Controller" brauchen.
Normalerweise schreibe ich Anwendungen in Client-Server Modell:
Server enthält die gesamte Geschäftslogik und weiß nichts über die GUI. Es macht die Hauptarbeit, und es ist so beweglich wie möglich.
client ist eine GUI, sie bindet an den Server, interagiert mit dem Benutzer, sendet Befehle vom Benutzer an den Server .
Ich mag diese Architektur, und ich kann nicht herausfinden, warum Leute wirklich ein Medium zwischen Client und Server brauchen, die Controller zu sein scheinen ?
UPD: einfaches Beispiel: Angenommen, wir müssen einen Datenlogger schreiben. Die Daten stammen vom COM-Port, der von einem Protokoll kodiert wird. Müssen empfangene Nachrichten in einem einfachen Protokollfenster anzeigen.
Wie würde ich es machen:
Server enthält die folgenden Elemente:
Data_receiver : empfängt tatsächlich Rohdaten vom COM-Port, aber es ist eine Schnittstelle, so dass wir eine andere Klasse erstellen können, die Daten von einer anderen Quelle empfängt; Data_decoder : nimmt Rohdaten und gibt die resultierenden decodierten Nachrichten zurück, es ist auch die Schnittstelle, so dass wir das Verschlüsselungsprotokoll leicht ändern können; Data_core : verwendet Instanzen von Data_receiver und Data_decoder , sendet Signale an Clients. Client enthält die folgenden Elemente:
Data_receiver (die Verbindung zum COM-Port), Data_decoder und Data_core (die Referenzen auf Data_receiver und Data_decoder Instanzen verwendet), erstellt auch ein einfaches GUI-Protokollfenster (das bezieht sich auf Data_core ); Data_core , d. h. überwacht die von ihm ausgegebenen Signale und zeigt empfangene Daten an. Nachdem ich verstanden habe, was ich über MVC gelesen habe, sollte die GUI keine empfangenen Nachrichten von Data_core empfangen, weil Controller das tun und dann Daten an die GUI übergeben soll. Aber was passiert, wenn GUI diese Daten direkt vom Modell übernimmt?
In der Vergangenheit habe ich mir dieselbe Frage viele Male gestellt und ich habe kürzlich über JSP Modell 2 Architektur gelesen, und der Wikipedia Eintrag gibt folgendes an:
Die Literatur zu Web-Tier-Technologie in der J2EE-Plattform verwendet häufig die Begriffe "Modell 1" und "Modell 2" ohne Erklärung. Diese Terminologie stammt aus frühen Entwürfen der JSP-Spezifikation, die zwei grundlegende Nutzungsmuster für JSP-Seiten beschrieben. Während die Begriffe aus dem Spezifikationsdokument verschwunden sind, bleiben sie weiterhin gebräuchlich. Modell 1 und Modell 2 beziehen sich einfach auf die Abwesenheit bzw. das Vorhandensein eines Controller-Servlets, das Anforderungen von der Client-Schicht absetzt und Ansichten auswählt.
Das bedeutet im Grunde, dass das MVC-Muster selbst variiert, so dass Sie je nach Projekt immer ein MVC- oder MV-Muster anwenden können. Eine richtige MVC-Architektur sollte jedoch einen Controller haben, da das Modell und die Ansicht nicht direkt miteinander kommunizieren sollten.
"Client-Server" hat nichts mit MVC, afaik zu tun.
Ich verstehe es so:
Model ist die Art, wie Sie Ihre Daten strukturieren. View ist die sichtbare Darstellung. (GUI) Controller verwendet die Logik, um die Ansicht und / oder andere Logik zu steuern. Die Idee dahinter ist es, die visuelle Darstellung von der Logik zu trennen. Also, wenn Sie die Ansicht greifen, duplizieren Sie nicht die Logik. ... in Ihrem Fall können Sie MVC nur auf der Client-Seite verwenden und Sie benötigen einen Controller, weil das die ganze Magie passiert.
Ich denke an MVVM Muster beim Lesen der Details Ihres Client-Server-Musters. Wenn Sie Komponententests durchführen möchten, ist es besser, die VM (ViewModel) als Controller zu betrachten.
Gemäß Ihrem Muster, einem klassischen Client / Server-Muster, leben der Controller, das Modell und die View im Servercode, den Sie Data_receiver, Data_decoder und Data_core aufrufen. In Ihrem "Client" haben Sie wieder einen Controller und sehen.
Es ist nützlich, einen Controller zu trennen, der die Signale und Daten von der COM empfängt und entschlüsselt, ein Modell, zu dem der Controller Daten auf dem Weg zur und von der Datenbank übergibt, eine Ansicht, die codiert und formatiert die Rohdaten aus dem Modell.
Wenn Sie dem Prinzip "Do not Repair Yourself" (DRY) folgen, werden Sie feststellen, dass sowohl im Server- als auch im Client-Bereich Ihres Codes Controllercode vorhanden ist, in dem Sie den Code oder die Verantwortlichkeiten wiederholen.
Es ist nützlich, wenn Sie Ihre Entwicklung in der Test Driven Development-Mode in verschiedene Teile unterteilen, so dass Sie verschiedene Tests anhängen können.
Besser spät als nie Ich möchte Ihre Fehlinterpretation von "Warum eine weitere Schicht zwischen Client und Server benötigt wird" korrigieren.
Wenn Sie die folgenden Zeilen durchgehen, ist die Antwort glasklar, dass MVC ein Dreiecksmodell der Architektur ist.
View fragt nach Model, fragt Controller, Controller verarbeitet es und sendet zurück an View.
%Vor%Grüße, Pavan.G
Tags und Links model-view-controller client-server application-design