Model View Controller: Verständnisproblem

[sp2017]

Eventuell eine blöde Frage, aber ich bin gerade etwas verwirrt. Ich bin dabei eine GUI application zu erstellen und versuche mich am MVC pattern zu halten. Kurz erklärt: Der User kann über das GUI auswählen, welche Named Entity Extraction APIs gewählt werden sollen (angenommen es stehen 4 zur Auswahl, dabei kann er dann 1 oder alle 4 APIs wählen) und zusätzlich kann sich der User noch die Korrelation zwischen den erhaltenen entities berechnen lassen.
Mir ist klar das eben view mein UI darstellt, controller für Erstellung und Update der View zuständig ist und model die Daten zur Verfügung stellt (z.B. Daten in einem File updaten).

Für meinen Fall, ist mir jetzt nicht klar, was alles eben in das model kommt, gibt man den ganzen Code z.B. zum Extrahieren der Entities und zur Berechnung der Korrelation in die model Klasse, oder habe ich hier nur eine Methode, die dann die entsprechende Korrelation Klasse z.B. aufruft?
Danke

 

[mrBrown]

Für meinen Fall, ist mir jetzt nicht klar, was alles eben in das model kommt, gibt man den ganzen Code z.B. zum Extrahieren der Entities und zur Berechnung der Korrelation in die model Klasse, oder habe ich hier nur eine Methode, die dann die entsprechende Korrelation Klasse z.B. aufruft?

Ersteres 😉

Ich würde alle zu den Daten gehörende Logik ins Model schieben, und der Controller ist dann nur noch für die Behandlung der Events aus der View zuständig.

 

[sp2017]

Danke 🙂

 

[Thallius]

Ersteres 😉

Ich würde alle zu den Daten gehörende Logik ins Model schieben, und der Controller ist dann nur noch für die Behandlung der Events aus der View zuständig.

Womit du die Austauschbarkeit des Modells, ein essentieller Grundgedanke des MVC, unmöglich machst.

Die Logik gehört natürlich in den Controller. Wobei dich niemand daran hindert den Controller in mehrere Schichten aufzuteilen. Also quasi dann ein MVCC. Das hält den Controller Teil dann übersichtlicher.

Gruß

Claus

 

[mrBrown]

Womit du die Austauschbarkeit des Modells, ein essentieller Grundgedanke des MVC, unmöglich machst.

Die Logik gehört natürlich in den Controller. Wobei dich niemand daran hindert den Controller in mehrere Schichten aufzuteilen. Also quasi dann ein MVCC. Das hält den Controller Teil dann übersichtlicher.

WTF, irgendwas hast du Grundlegend nicht verstanden. Lies dir mal bitte irgendeinen guten Artikel zu MVC durch.

Nicht die Austauschbarkeit des Models ist Ziel, sondern die Entkopplung aller drei Komponenten.
Das impliziert durchaus, dass man das Model (gleiches Interface vorrausgesetzt) austauschen kann - generell geht es aber eher um die Austauschbarkeit von View (ein Model - mehrere Ansichten) und der Controller.


Wenn man wie in deinem Vorschlag die Logik im Controller und die Daten im Model hat, bricht man vollkommen damit und auch mit generellem Objekt-Orientiertem Design.

Bei dir ist genau gar nichts austauschbar, wenn Logik und Daten getrennt sind.
Man kann das Model austauschen - aber auch nur gegen ein identisches (was sowieso völliger Unsinn ist - die gleiche View soll verschiedene Models ohne Anpassung darstellen, quasi erst Konten, dann Eisbecher oder so?).
Man kann den Controller austauschen, aber dann hat man keine Logik mehr und kann mit dem Model nichts anfangen.
Man kann es nichtmal vernünftig testen, das Model enthält ja keine testbare Logik, und der Controller braucht die View, dies in nem Test erstmal so nicht gibt.


Ganz anders, wenn das Model auch die Logik der Domäne enthält.

Man kann es wunderbar testen - das Model enthält die relevante (von der View unabhängige) Logik.
Man kann wunderbar ein anderes View-Controller-Paar zum anzeigen des Models benutzen - die relevanten Teile stecken ja im Model.
Man kann das Model auch einfach völlig ohne View mit CLI oder in ner WebApp verwenden - die Domänenlogik steckt schließlich im Model, und nur der Darstellungspart (= VC) wird ersetzt.

 

[sp2017]

Ich habe zu meiner ursprünglichen Frage noch eine Frage.

Die GUI sieht nach wie vor so aus wie beschrieben: Der User kann über das GUI auswählen, welche Named Entity Extraction APIs gewählt werden sollen (angenommen es stehen 4 zur Auswahl, dabei kann er dann 1 oder alle 4 APIs wählen) und zusätzlich wird noch die Korrelation zwischen den erhaltenen entities berechnet.

Jetzt soll dem User am Ende in der View die Korrelation angezeigt werden. Dazu benötige ich zuerst die Methode zur entity extraction und erst danach kann die Korrelation berechnet werden. Da ich ja verschiede APIs zur Verfügung habe, muss ich wissen welche API der User für die Entity Extraction gewählt hat.

Mir ist klar das ich zunächst mal überprüfen muss, welche API gewählt wurde. Nur wird diese Überprüfung dann im Controller durchgeführt und dann vom Controller die passende Methode zur extraction aus dem Model aufgerufen. Oder wird vom Controller das Model aufgerufen und dort dann überprüft welche API gewählt wurde und dann die jeweilige Methode im Model?

 

[mrBrown]

Beides ist möglich, das hängt ein bisschen davon ab, wie die Auswahl und Model/Controller umgesetzt sind.

Wie sehen denn bei dir grob Model und Controller aus?
Sind die einzelnen APIs als Objekte vorhanden?

 

[truesoul]

Hallo.

Im Internet gibt es zwei Varianten die man in etlichen Artikel findet zu MVC.

1. Model (Datenschicht ohne Logik), Controller (sämtliche Logik), View (Ansicht)
2. Model (Buisness Logik und Datenhaltung), Controller (Event Handling), View (Ansicht)

Ich persönlich mag die 2 Variante mehr, weil Sie sich richtiger anfühlt. Und mrBrown auch auch dazu eine gute Erklärung gebracht.
Wenn man sich das beide Beispiele anschaut sieht man vielleicht auch, welche sich besser (sinnvoller) testen lassen und welche besser "austauschbar" sind.

Ich finde man sollte auch andere Entwurfsmuster in betracht ziehen.

Model View Viewmodel (MVVM)

• https://msdn.microsoft.com/library/windows/apps/jj721615(v=vs.105).aspx
  
• In Angular verwendet man häufig MVVM/MVC

Model View Presenter (MVP)

• Die View ist besser entkoppelt vom Model. Der Presenter ist dafür verantwortlich das Model an die View zu binden
• Einfacher zu testen, da die Interaktion mit der View über eine Schnittstelle erfolgt
• Komplexe View's können mehrere Presenter haben. Normalerweise sehen sich die Presenter und View 1 zu 1 gegenüber.

Grüße

 

[mrBrown]

Im Internet gibt es zwei Varianten die man in etlichen Artikel findet zu MVC.

1. Model (Datenschicht ohne Logik), Controller (sämtliche Logik), View (Ansicht)
2. Model (Buisness Logik und Datenhaltung), Controller (Event Handling), View (Ansicht)

Ich persönlich mag die 2 Variante mehr, weil Sie sich richtiger anfühlt. Und mrBrown auch auch dazu eine gute Erklärung gebracht.
Wenn man sich das beide Beispiele anschaut sieht man vielleicht auch, welche sich besser (sinnvoller) testen lassen und welche besser "austauschbar" sind.

Wie oben schon mal gesagt: Auch wenn es etliche Artikel zu ersterem sind, gute Artikel oder gar Argrumente sind da nicht drunter 😉

Ich finde man sollte auch andere Entwurfsmuster in betracht ziehen.

Model View Viewmodel (MVVM

Model View Presenter (MVP)

Für beide sollte man aber MVC verstanden haben 😛
Das M bleibt bei vernünftiger Umsetzung auch in allen gleich, dann kann man problemlos wechseln 😀

 

[sp2017]

Ich weiss das es etliche Artikel online dazu gibt, darum bin ich auch etwas verwirrt weil überall etwas anderes steht.

Ja, die APIs sind als Objekte vorhanden. Im Prinzip wird in der View nur angegeben welche API benutzt werden soll und welche Korrelation (3 verschiedene sind vorhanden) und hier können dann alle vorhandenen APIs und Korrelationskoeffizienten oder nur eine oder 2,… gewählt werden, und über einen Button sollte dann eben die Entity extraction (mit den zuvor vom User gewählten APIs) ausgeführt werden und im Anschluss die Berechnung der Korrelation (auch mit den zuvor vom User gewählten Möglichkeiten).

 

[mrBrown]

Die Überprüfung, welche gewählt ist, sollte im Controller stattfinden - das Model weiß ja dann erstmal nicht, wie überhaupt gewählt wird.

Das gewählte gibst du dann an irgendeine Klasse aus dem Model weiter, und das macht dann das geforderte mit den Daten

 

[sp2017]

Alles klar, danke 🙂

 

[andy82]

...
Für meinen Fall, ist mir jetzt nicht klar, was alles eben in das model kommt, gibt man den ganzen Code z.B. zum Extrahieren der Entities und zur Berechnung der Korrelation in die model Klasse, oder habe ich hier nur eine Methode, die dann die entsprechende Korrelation Klasse z.B. aufruft?
Danke

In der Praxis (z.B. einer großen Desktop-Anwendung) ist ein MVC-Konstrukt nur ein logischen Teil (von Fall zu Fall möglich nicht kleinerer teilbar ???) von mehreren logischen MVC-Teilen einer GUI (Frame, Stage...), daher gehört die Logik, z.B wie Daten aus der Datenbank bekommt, berechnet ... nicht zu einem MVC-Konstrukt, sondern zu anderen Schichten wie Business Process, Persistence Manager, Wrapper-Schicht ... Beispiel einer Kunden-Liste (nur ein Teil der GUI):
Model: ObservableList<Kunden>, ArrayList<Kunden>, ListModel ...
View: ListView, JList ...
Controller: erhält Steuerung, wie Kunden-Liste angezeigt...
- Sollte ein Kunde selektiert, sendet Controller Event an übergeordneten Controller (Application, BusinessProcess ..., die mehreren Controller steuern, einschließlich dies!). Ein weitere Controller eines MVC-Konstrukt (z.B. Zeige Kunden-Attributes) bekommt Event, leitet, steuern intern an seinen Model, View ...
- Sollte Änderungen für dieser Kunde passiert sein (egal ob nur temporär geändert (noch nicht save!) oder endgültig...), die Steuerung sollte nicht in diesem Controller passieren, sondern in Business Object, Persistence Manager, Wrapper-Schichten ... getan werden. Dort werde auch die Zustände eines Objects (transient, change, save, delete ...) definiert.

 

[mrBrown]

In der Praxis (z.B. einer großen Desktop-Anwendung) ist ein MVC-Konstrukt nur ein logischen Teil (von Fall zu Fall möglich nicht kleinerer teilbar ???) von mehreren logischen MVC-Teilen einer GUI (Frame, Stage...), daher gehört die Logik, z.B wie Daten aus der Datenbank bekommt, berechnet ... nicht zu einem MVC-Konstrukt, sondern zu anderen Schichten wie Business Process, Persistence Manager, Wrapper-Schicht ... Beispiel einer Kunden-Liste (nur ein Teil der GUI):

Das ist das 'M' in MVC...

Model: ObservableList<Kunden>, ArrayList<Kunden>, ListModel ...

Von denen würde ich nur Kunden und ArrayList ins reine Domain-Model einordnen.
ObservableList und ListModel sind an bestimmte GUI-Frameworks gebunden, die gehören tendenziell eher in ein ViewModel