Ganz einfaches MVC-Beispiel?!

[Marco13]

Hm - man unterscheidet da wohl grundsätzlich zwischen einem "Active Model" und eine "Passive Model".

Das passive wird NUR vom Controller geändert, und der weiß dann auch, dass er danach der View bescheid sagen muss, sie möge sich bitte updaten.

Das aktive Model wirft selbst die Events, und die View ist als Listener/Observer angehängt.

In welcher Hinsicht soll es "gefährlich" werden, wenn beide Seiten Events werfen? (Abgesehen vom potentiellen Problem, dass Model und View sich gegenseitig in einem Endlos-Pingpong Events zuschachern - dass muss man vermeiden, indem man wirklich NUR Events wirft, wenn sich wirklich etwas geändert hat)

 

[Stefan S.]

Ich habe eine Frage: sollten wir mit dem Einsatz von Modelevents nicht vorsichtig sein? Sollten die Events nicht möglichst nur von der View ausgehen? Jedenfalls scheint's mir gefährlich zu werden, wenn von zwei Seiten geschossen wird, oder wie seht ihr das?

Das Model sollte überhaupt nicht auf Userereignisse reagieren. Zitat:

Is the domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model.Model?view?controller - Wikipedia, the free encyclopedia

Das Modell stellt nur die Anwendungslogik für die Datenschicht bereit!

Ohje, stimmt. Was ich beschrieben hab kommt schon eher aus der Model-View-Adapter-Architektur (wenn man "Controller" durch "Adapter" austauscht). Oder bin ich dabei noch immer auf dem Holzweg?

Fast. Das MVA Muster grenzt die View noch stärker vom Model ab. Es ist prinzipiell ein von MVC abgeleitetes Muster, bei dem die Schranken etwas stärker definiert sind.

 

[Ebenius]

Fast. Das MVA Muster grenzt die View noch stärker vom Model ab. Es ist prinzipiell ein von MVC abgeleitetes Muster, bei dem die Schranken etwas stärker definiert sind.

Du meinst: Die View darf dazu auch keine Daten vom Modell holen, sondern bekommt sie vom Adapter mitgeteilt. Den Teil hatte ich eigentlich gar nicht explizit erwähnt. Oder meinst Du noch einen anderen Punkt?

Ebenius

 

[Stefan S.]

Du meinst: Die View darf dazu auch keine Daten vom Modell holen, sondern bekommt sie vom Adapter mitgeteilt.

Bingo!

Beim normalen MVC ist es durchaus nicht unüblich das die View das Model nach dessen Status abfragt. Es sollte zwar niemals Daten im Modell ändern, aber es darf durchaus den Zustand abfragen. Das ist beim MVA etwas strenger geregelt. Dort ruft es das Model überhaupt nicht auf.

Eigentlich ist das reine zusammengesetzte MVC-Muster elegant, solange man gegen ein Interface programmiert.

Zu Entwurfsmustern empfehle ich das Standardwerk der Gang of Four.

 

[Wildcard]

Eigentlich ist das reine MVC Entwurfsmuster optimal, solange man gegen ein Interface programmiert.

Zu Entwurfsmustern empfehle ich das Standardwerk der Gang of Four.

Nur ist MVC kein Entwurfsmuster, sondern ein Architekturmuster

 

[Ebenius]

Zu Entwurfsmustern empfehle ich das Standardwerk der Gang of Four.

-Entwurfs+Architektur

Derzeit hält mich leider Benjamin von Stuckrad-Barres Livealbum sehr aktiv davon ab.

Ebenius

 

[Gast2]

okay das war mir jetzt ein bischen viel (vielleicht morgen nochmal lesen)...
Wenn Ihr euch alle versteht^^ könnte das mal jemand an einem Beispiel kurz nochmal erklären??????:L

 

[Wildcard]

Derzeit hält mich leider Benjamin von Stuckrad-Barres Livealbum sehr aktiv davon ab.

Mach dir nichts draus, das Buch behandelt sowieso keine Architekturmuster. Es sagt lediglich: MVC ist kein Entwurfsmuster bei der allgemeinen Erklärung was denn nun ein Entwurfsmuster sei :bae:

 

[Stefan S.]

Nur ist MVC kein Entwurfsmuster, sondern ein Architekturmuster

Das ist richtig. Das MVC setzt sich aus 3 elementaren Entwurfsmustern zusammen, Observer, Strategy und Composite. Ich bezeichne es meist als zusammengesetztes Entwurfsmuster.

 

[Wildcard]

Eigentlich ist das reine MVC Entwurfsmuster optimal, solange man gegen ein Interface programmiert.

Wie kommst du darauf das es 'optimal' sei? MVC ist weder das einzig richtige, noch das flexibelste und ausserdem ist es recht schwierig die Trennung sauber aufrecht zu erhalten.
MVA hat zB durchaus schlagkräftige Argumente, ebenso wie naked objects.
Heißt ja nun nicht das solche Ansätze grundsätzlich zu bevorzugen wären, aber 'optimal' ist schon eine bestenfalls zweifelhafte Aussage.

 

[Stefan S.]

okay das war mir jetzt ein bischen viel (vielleicht morgen nochmal lesen)...
Wenn Ihr euch alle versteht^^ könnte das mal jemand an einem Beispiel kurz nochmal erklären???

Noch ne Frage: wo benachrichtigt ihr die listeners/views, dass sich das model geändert hat?

im controller? oder im model??? ...

Informiere dich über Java Observable und Observer. Das Model erweitert die Klasse Observable, die View implementiert das Interface Observer. Beim Start registriert sich die View beim Model. Ändern sich Daten im Model, werden alle Observer mithilfe von setChanged() und notifyObservers() benachrichtigt.

 

[Stefan S.]

Wie kommst du darauf das es 'optimal' sei? MVC ist weder das einzig richtige, noch das flexibelste

Ich sagte nicht dass das MVC Muster das Beste Muster sei, ich sagte das es im Vergleich zum MVA meiner Ansicht nach optimal sei, sofern man einige Richtlinien beachtet.

und ausserdem ist es recht schwierig die Trennung sauber aufrecht zu erhalten.

Ansichtssache.

Heißt ja nun nicht das solche Ansätze grundsätzlich zu bevorzugen wären, aber 'optimal' ist schon eine bestenfalls zweifelhafte Aussage.

Jetzt wollen wir hier aber nicht den Korinthenkacker spielen, oder?

EDIT: Ich habe das absolute Adjektiv nun ausgetauscht. Das dürfte dich hoffentlich zufrieden stellen.

 

[Wildcard]

Weniger absolute Aussagen finde ich in diesem Zusammenhang treffender, richtig, aber davon abgesehen interessiert es mich schon. Warum ist für dich MVC zB besser als MVA?
Ich muss mir nur Swing MVC ansehen und bin schon genervt von den ListModels, TableModels, ComboCellModels, TreeModels,...
Den Adapter Ansatz finde ich da persönlich ansprechender.

 

[Stefan S.]

Weniger absolute Aussagen finde ich in diesem Zusammenhang treffender, richtig,

Ich bin auch kein Fan von absoluten Aussagen. Insbesondere wenn Begriffe, wie immer oder nie fallen. Machmal fallen sie aber im Eifer des Gefechts trotzdem.

aber davon abgesehen interessiert es mich schon. Warum ist für dich MVC zB besser als MVA?

Das MVC ist meiner Ansicht nach etwas flexibler und dennoch sauber programmierbar, sofern man sich an einige Richtlinien hält. Letztlich ist es aber eine Frage der Anforderungen.

Ich muss mir nur Swing MVC ansehen und bin schon genervt von den ListModels, TableModels, ComboCellModels, TreeModels,...
Den Adapter Ansatz finde ich da persönlich ansprechender.

Das ist natürlich subjektiv zu bewerten und von Programmierer zu Programmierer unterschiedlich.

 

[Wildcard]

Das MVC ist meiner Ansicht nach etwas flexibler und dennoch sauber programmierbar, sofern man sich an einige Richtlinien hält. Letztlich ist es aber eine Frage der Anforderungen.

Das musst du jetzt aber schon erläutern, denn es gibt nur deshalb MVA, weil MVC nicht flexibel genug war (View and Modell gekoppelt).

 

[Stefan S.]

Das musst du jetzt aber schon erläutern, denn es gibt nur deshalb MVA, weil MVC nicht flexibel genug war (View and Modell gekoppelt).

Die Frage ist nun was du unter flexibel verstehst. Wenn du damit meinst das MVA den Vorteil bietet das die View sauber getrennt ist und Model sowie View sehr einfach austauschbar, dann hast du recht.

Ich verstehe unter Flexibilität allerdings den Vorteil von MVC in einer 2-Stufen Hierarchie arbeiten zu können, ohne die Komplexität zu steigern. Beim MVA benötigst du zusätzliche Mechanismen, wie Datenbindung und Auto-Updating um das zu erreichen.

 

[Wildcard]

Aber Databinding führt doch keine zusätzliche Komplexität ein, sondern vereinfacht die Sache ganz erheblich. Es ist wesentlich weniger Code notwendig, der Code ist robust, die Teile sauber getrennt und besser austauschbar.
Das lässt sich natürlich auch mit MVC erreichen (bis auch die Sache das View an Model gekoppelt ist), aber bei MVC brauchst du dann einen sehr erfahrenen Entwickler, bei MVA reicht ein weniger erfahrener.

 

[André Uhres]

Das Model sollte überhaupt nicht auf Userereignisse reagieren.

Aber der Controller reagiert ja auf Userereignisse und ändert dann das Model, nicht wahr? Wenn jetzt der Controller auch noch die Views ändert, bräuchte man ja gar keine Modelereignisse, oder? Der Controller (also nicht das Model) ist in dem Fall der Observable, wie es in unseren FAQ auch gezeigt wird.

 

[Ebenius]

Ich muss mir nur Swing MVC ansehen und bin schon genervt von den ListModels, TableModels, ComboCellModels, TreeModels,...

ComboCellModels...

Genau dieses Konzept gefällt mir an Swing unheimlich. Den direkten Vergleich zu SWT kann ich leider nicht ziehen. Mich dort soweit einzuarbeiten, dass ich dafür ein Gefühl bekomme, macht mir etwas zu viel Mühe.

Ebenius

 

[Gast2]

Könnte einer mal MVC und MVA gegenüber stellen, damit man mal den unterschied sieht?

Okay nochmal paar Fragen:
Wenn alle Views sich beim Model registrieren...Und das Model alle Views benachrichtigt
für was braucht man dann noch den Controller??? Eine View kann ja dann direkt das Model ändern????
Hat die View dann eine Instanz vom Model?

ich hab das bis jetzt so verstanden, dass die views sich beim controller registrieren, die controller das model ändern und der controller alle views benachrichtigt(so wie in meinem anfangs bsp)... Ach ja mein Besipiel ist ja so ähnlich wie in der FAQ...

Finde schade dass ihr das Thema so theoretisch behandelt...
Kommen genau die gleichen Fragen auf wie wenn man es in irgendwo etc. nachliest...

 

[Stefan S.]

aber bei MVC brauchst du dann einen sehr erfahrenen Entwickler, bei MVA reicht ein weniger erfahrener.

Richtig. Ich bin allerdings kein Fan von aufgeblasenen Mustern, die das Abstraktionsniveau auf ein zu hohes Level heben.

Aber der Controller reagiert ja auf Userereignisse und ändert dann das Model, nicht wahr? Wenn jetzt der Controller auch noch die Views ändert, bräuchte man ja gar keine Modelereignisse, oder? Der Controller (also nicht das Model) ist in dem Fall der Observable, wie es in unseren FAQ auch gezeigt wird.

Was sind Modelereignisse? Die View ist lediglich die Ansicht des Benutzers auf das Model.

Okay nochmal paar Fragen:
Wenn alle Views sich beim Model registrieren...Und das Model alle Views benachrichtigt
für was braucht man dann noch den Controller??? Eine View kann ja dann direkt das Model ändern????
Hat die View dann eine Instanz vom Model?

ich hab das bis jetzt so verstanden, dass die views sich beim controller registrieren, die controller das model ändern und der controller alle views benachrichtigt(so wie in meinem anfangs bsp)... Ach ja mein Besipiel ist ja so ähnlich wie in der FAQ...

Finde schade dass ihr das Thema so theoretisch behandelt...
Kommen genau die gleichen Fragen auf wie wenn man es in irgendwo etc. nachliest...

Wer behandelt das Thema theoretisch?

Die View hat eine Instanz vom Model, primär natürlich um sich mit addObserver() beim Model als Beobachter einzutragen.

Der Controller übernimmt die Steuerung der Benutzereingaben. Ich drücke den Button on(), die View ruft daraufhin controller.on() auf. Dieser implementiert nun die Steuerungslogik, d.h. er bestimmt nun, was zu tun ist. Das kann zum Beispiel den Aufruf des Models beinhalten, mit dem Daten initialisiert werden und die Abschaltung des On-Buttuns (setEnabled( false) ) in der View.

Siehe

http://students.cs.byu.edu/~cs340ta/winter2009/hw/homeworks/Homework-05-MVC.pdf

Schau dir einmal größere Beispielapplikationen, wie Joomla 1.5 an. Dort wurde das MVC sehr schön umgesetzt.

 

[mvitz]

...
Was sind Modelereignisse?
...

Er meint damit vermutlich, dass das Model die View dann nicht mehr per Observer benachrichtigen muss, da dass ja dann auch durch den Controller geschehen kann.

...
Der Controller übernimmt die Steuerung der Benutzereingaben. Ich drücke den Button on(), die View ruft daraufhin controller.on() auf. Dieser implementiert nun die Steuerungslogik, d.h. er bestimmt nun, was zu tun ist. Das kann zum Beispiel den Aufruf des Models beinhalten, mit dem Daten initialisiert werden und die Abschaltung des On-Buttuns (setEnabled( false) ) in der View.

Hier kriege ich z.B. unter Swing immer wieder meine Probleme, wenn ich mehrere Panels habe, die alle denselben Controller verwenden sollen um z.B. ein Panel zur Dateieingabe und ein anderes zur Datenausgabe zu haben (vermutlich ist es ganz einfach, aber ich habe noch keinen Weg gefunden, der mir irgendwie 100% zusagt.

...
Schau dir einmal größere Beispielapplikationen, wie Joomla 1.5 an. Dort wurde das MVC sehr schön umgesetzt.
...

Da muss man finde ich nochmal stark unterscheiden. Joomla 1.5 ist eine Webapplikation. Meiner Meinung nach, ist es in einer Webapplikation wesentlich leichter MVC zu trennen, als in einer SwingApplikation, da du ja immer mit Response arbeitest und nicht wie in Swing nur einen Teil neu laden musst.

 

[Wildcard]

Genau dieses Konzept gefällt mir an Swing unheimlich. Den direkten Vergleich zu SWT kann ich leider nicht ziehen. Mich dort soweit einzuarbeiten, dass ich dafür ein Gefühl bekomme, macht mir etwas zu viel Mühe.

Üblicherweise sieht das so aus:
[HIGHLIGHT="Java"]TreeViewer viewer = new TreeViewer(parent);
viewer.setContentProvider(aTreeContentProvider);
viewer.setLabelProvider(aLabelProvider);
viewer.setInput((Object)myModel);[/HIGHLIGHT]

Model ist völlig beliebig, Object.
Der ContentProvider übersetzt das Model für den Viewer (der Adapter).
Der LabelProvider stellt labels und Icons bereit.

typischer contentprovider:

[HIGHLIGHT="Java"]Object[] getChildren(Object parent){
return ((MyDomainModelContainer)parent).getFooChildren().toArray();
}[/HIGHLIGHT]


typischer LabelProvider:

[HIGHLIGHT="Java"]String getText(Object o){
return ((MyDomainModel)o).getName();
}

ImageDescriptor getIcon(Object o){
if(o instanceof MyDomainModelFoo){
return ImageRegistry.getImage("foo");
}
}[/HIGHLIGHT]

Sehr wenig Code, wiederverwendbare Label und ContentProvider, View und Model entkoppelt.
Idealerweise koppelt man das nun für die Benutzerinteraktion mit JFace Databinding.

 

[Gast2]

Richtig. Ich bin allerdings kein Fan von aufgeblasenen Mustern, die das Abstraktionsniveau auf ein zu hohes Level heben.



Was sind Modelereignisse? Die View ist lediglich die Ansicht des Benutzers auf das Model.



Wer behandelt das Thema theoretisch?

Die View hat eine Instanz vom Model, primär natürlich um sich mit addObserver() beim Model als Beobachter einzutragen.

Der Controller übernimmt die Steuerung der Benutzereingaben. Ich drücke den Button on(), die View ruft daraufhin controller.on() auf. Dieser implementiert nun die Steuerungslogik, d.h. er bestimmt nun, was zu tun ist. Das kann zum Beispiel den Aufruf des Models beinhalten, mit dem Daten initialisiert werden und die Abschaltung des On-Buttuns (setEnabled( false) ) in der View.

Siehe

http://students.cs.byu.edu/~cs340ta/winter2009/hw/homeworks/Homework-05-MVC.pdf

Schau dir einmal größere Beispielapplikationen, wie Joomla 1.5 an. Dort wurde das MVC sehr schön umgesetzt.

was spricht dagegen die views beim controller zu registrieren ????
was spricht dagegen dass der controller die views benachrichtigt???

Sehr wenig Code, wiederverwendbare Label und ContentProvider, View und Model entkoppelt.

Aber nur für das gleiche Model wiederverwendbar sonst müsstest ja alles mit instanceOf unterscheiden...

 

[Wildcard]

Aber nur für das gleiche Model wiederverwendbar sonst müsstest ja alles mit instanceOf unterscheiden...

Zum einen ist so ein ContentProvider sehr schlank, zum anderen ist es sinn des ganzen ihn für genau ein Model zu erstellen. Diesen ContentProvider kannst du dann aber für viele verschiedene Views auf das gleiche Model verwenden.
In EMF wird zB in einer AdapterFactory ein 'universal' ContentProvider erzeugt der für Listen, Tabellen, Bäume,... passt.

 

[Stefan S.]

was spricht dagegen die views beim controller zu registrieren ????

Weil das kein MVC mehr ist, das ist eine eigenwillige Interpretation. Wozu sollten sich die Views beim Controller registrieren, der Controller übersetzt nur Benutzersteuerungen.

was spricht dagegen dass der controller die views benachrichtigt???

Er banachrichtigt doch die Views, falls das notwendig ist.

Ich habe auch keine Lust hier zehnmal dasselbe zu schreiben. Ich habe dir einen expliziten Link oben gegeben, samt Lektüre. Hier ist noch ein guter, den ich gerade mit Google auf die Schnelle gefunden habe:

model/view/controller

Und hier das offizielle Java Buch "Head First Design Patterns ".

Head First Design Patterns | O'Reilly Media

Da steht alles was es über MVC zu wissen gibt, samt Codebeispielen. Die gibts dort kostenlos zum runterladen.

Die Torte quasi mit Zuckerguß oben drauf. Ende der Durchsage! ;(

 

[Gast2]

Weil das kein MVC mehr ist, das ist eine eigenwillige Interpretation. Wozu sollten sich die Views beim Controller registrieren, der Controller übersetzt nur Benutzersteuerungen.



Er banachrichtigt doch die Views, falls das notwendig ist.

Ich habe auch keine Lust hier zehnmal dasselbe zu schreiben. Ich habe dir einen expliziten Link oben gegeben, samt Lektüre. Hier ist noch ein guter, den ich gerade mit Google auf die Schnelle gefunden habe:

model/view/controller

Und hier das offizielle Java Buch "Head First Design Patterns ".

Head First Design Patterns | O'Reilly Media

Da steht alles was es über MVC zu wissen gibt, samt Codebeispielen. Die gibts dort kostenlos zum runterladen.

Die Torte quasi mit Zuckerguß oben drauf. Ende der Durchsage! ;(

Ich weiß langsam was du meinst ich habs mir jetzt 100 mal durchgelesen...
Du solltest mehr auf die Frage eingehen und nicht 100000 mal das gleiche runterlabern davon hat kein Mensch was gesagt.
1. Ist es nicht nur meine Interprtation http://www.java-forum.org/51799-post11.html
hier ist es genau so gemacht dass der controller die views registriert...
2. Ich hab verstanden, dass es (meistens) so gemacht wird, aber ich hab gefragt was dagegen spricht, die views beim controller aufzunehmen und eine antwort es ist kein MVC ist ein schlechtes Argument(find ich), ein Argument mit einem richtigen Nachrteil würde mich mehr Überzeugen...

@Wildcard
Hat mich überzeugt klingt einleuchtend

 

[André Uhres]

Weil das kein MVC mehr ist, das ist eine eigenwillige Interpretation. Wozu sollten sich die Views beim Controller registrieren, der Controller übersetzt nur Benutzersteuerungen.

Sollten unsere Mods und User wirklich alle so doof sein, daß sie einen gravierenden Fehler über vier Jahre lang nicht bemerkt hätten? In den FAQ wird MVC so erklärt:

public class WindController extends Observable implements WindControllable {
    private Wind wind;

    public WindController() {
        WindViewer viewer = new WindViewer( this );
        addObserver( viewer );
        wind = new Wind();
    }

 

[maki]

Für MVC und andere GUI Patterns hat Martin Fowler auch sehr gute Artikel:

GUI Architectures
Martin Fowler: eaaDev (unter "Presentation Patterns")

 

[Stefan S.]

Ich weiß langsam was du meinst ich habs mir jetzt 100 mal durchgelesen...
Du solltest mehr auf die Frage eingehen und nicht 100000 mal das gleiche runterlabern davon hat kein Mensch was gesagt.
1. Ist es nicht nur meine Interprtation http://www.java-forum.org/51799-post11.html
hier ist es genau so gemacht dass der controller die views registriert...

Ja genau. Du und die FAQ gegen den Rest der Welt.

Mach nur so weiter, mir ist das vollkommen egal.

2. Ich hab verstanden, dass es (meistens) so gemacht wird, aber ich hab gefragt was dagegen spricht, die views beim controller aufzunehmen und eine antwort es ist kein MVC ist ein schlechtes Argument(find ich), ein Argument mit einem richtigen Nachrteil würde mich mehr Überzeugen...

Ich habe dir bereits 10x erklärt warum das Model und nicht der Controller Observable erweitert. Falls du das noch immer nicht kappiert hast, ist es nicht mein Problem. Ich habe es auch nicht nötig, mich von dir für meine Hilfe beleidigen zu lassen nur weil du offensichtlich zu faul bist, dich durch die geposteten Links zu lesen. Deshalb landest du jetzt auf ignore.

 

[Ebenius]

Stefan S., eine Beleidigung kann ich nirgends finden.

André, meiner Meinung nach ist entweder der FAQ-Beitrag falsch, oder der Wikipedia Beitrag über MVC. Eines der beiden sollte geändert werden.

Controll - Ebene:
Die Klassen regeln die Kommunikation zwischen den Model und View. Sie dienen dazu Änderungen in den Model Klassen den View Klassen mitzuteilen bzw. vice versa.

vs.

Modell (model)
Das Modell enthält die darzustellenden Daten und gegebenenfalls (abhängig von der Implementation des MVC-Patterns) auch die Geschäftslogik. Es ist von Präsentation und Steuerung unabhängig. Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“.

Ebenius

 

[maki]

Denke man sollte MVC nicht überbewerten, zB. als echtes Muster
Ist mehr so etwas wie ein Konzept als ein Muster.
Selbst bei "echten" Mustern gibt es immer mehrere Wege der Implementierung.

Die "reinrassige" Implementierung ist in Smalltalk und hat sich seit dem öfters geändert.

 

[Ebenius]

Denke man sollte MVC nicht überbewerten

Das sehe ich in der Realität ähnlich. Wenn wir aber einen FAQ-Beitrag haben, der sich zur Aufgabe gemacht hat, das MVC-Muster zu erklären, dann sollte er dies wenigstens nicht falsch tun.

Ebenius

 

[Stefan S.]

Sollten unsere Mods und User wirklich alle so doof sein, daß sie einen gravierenden Fehler über vier Jahre lang nicht bemerkt hätten? In den FAQ wird MVC so erklärt:

public class WindController extends Observable implements WindControllable {
    private Wind wind;

    public WindController() {
        WindViewer viewer = new WindViewer( this );
        addObserver( viewer );
        wind = new Wind();
    }

Ganz offensichtlich wurde dieser Fehler bisher nicht bemerkt oder die meisten User haben ihn schlicht übersehen.

Die View ist die Sicht des Nutzers auf das Model, welches die vollständige Anwendungslogik der Daten enthält. Das Model kann seinen Zustand intern verändern, z.B. wenn ein Musikstück abgespielt wird. Darüber werden dann die Observer benachrichtigt. Es sollte recht deutlich zum Vorschein kommen das der Controller nicht der Observable sein kann, er ist schließlich nur die Steuerungskomponente der View, mit dem das Model und die View selbst ggf. beeinflusst werden.

Wenn beispielsweise das Model eine Uhr intern repräsentiert, die die Sekunden intern hochzählt, wie soll dann der Controller die View darüber benachrichtigen? Er bekommt doch von der Zustandsänderung der Daten überhaupt nichts mit.

Deshalb heißt es auch bei Wikipedia.

Das Modell enthält die darzustellenden Daten und gegebenenfalls (abhängig von der Implementation des MVC-Patterns) auch die Geschäftslogik. Es ist von Präsentation und Steuerung unabhängig. Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“.

Dasselbe sagt:

Class::MVC - model-view-controller paradigma - search.cpan.org
model/view/controller
Head First Design Patterns | O'Reilly Media
MVC: Model-View-Controller Design Pattern used in Struts, Ruby on Rails, etc
JavaTech: an introduction to ... - Google Book Search
http://harbormist.com/jett/pat/mvc.ppt
http://csdl.ics.hawaii.edu/~johnson/413f06/18.JavaGUI.pdf
:: christianroessler.net - forum / Model View Controller (MVC) - Konzept mit JAVA
http://www.sws.bfh.ch/~amrhein/Skripten/Swing/Pattern.pdf

und alle anderen Quellen, die es im Internet gibt.

Selbst im Buch der Go4 wird das so erklärt. Also entweder liegen hier selbst die Experten falsch oder die FAQ hier ist nicht korrekt. Sucht euch das Plausibelste aus.

 

[Stefan S.]

Stefan S., eine Beleidigung kann ich nirgends finden.

Ich schon. Ich zitiere:

Du solltest mehr auf die Frage eingehen und nicht 100000 mal das gleiche runterlabern davon hat kein Mensch was gesagt.

Beleidigungen werden immer subjektiv empfunden. Daher ist es mein gutes Recht diesen User auf meine Ignoreliste zu setzen.

 

[maki]

Das Modell enthält die darzustellenden Daten und gegebenenfalls (abhängig von der Implementation des MVC-Patterns) auch die Geschäftslogik. Es ist von Präsentation und Steuerung unabhängig. Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“.
...
Dasselbe sagt:
..
MVC: Model-View-Controller Design Pattern used in Struts, Ruby on Rails, etc

Das will ich sehen, wie struts per Beobachter Änderungen im Modell feststellt und daraufhin die View aktualisiert

Mal ernsthaft, eine wichtige Sache die mir bis jetzt in der Diskussion über MVC fehlt ist die Tatsache das es sich beim C in MVC, also dem Controller, um einen Frontcontroller handelt, nicht um einen Application-/BusinessController.

Das sehe ich in der Realität ähnlich. Wenn wir aber einen FAQ-Beitrag haben, der sich zur Aufgabe gemacht hat, das MVC-Muster zu erklären, dann sollte er dies wenigstens nicht falsch tun.

Das ist veständlich Ebenius und dem will ich auch gar nicht widersprechen.
Dachte nur das wir uns die "Beleidigungen" (sofern es denn wirklich welche gegeben haben sollte) für den nächsten SIngleton Thread aufheben sollten *g*

 

[Stefan S.]

Dachte nur das wir uns die "Beleidigungen" (sofern es denn wirklich welche gegeben haben sollte) für den nächsten SIngleton Thread aufheben sollten *g*

Gibt es etwa Meinungsunterschiede zum double-checked locking? Mit volatile müsste das Problem doch beseitigt sein.

 

[maki]

Gibt es etwa Meinungsunterschiede zum double-checked locking? Mit volatile müsste das Problem doch beseitigt sein.

Nee,

eher pro vs. contra Singletons, Anti-Pattern oder nicht, gutes Design oder nicht, testbarkeit, wie schlimm ist ein einziges Singleton in der App, etc. pp.

 

[Stefan S.]

Nee,

eher pro vs. contra Singletons, Anti-Pattern oder nicht, gutes Design oder nicht, testbarkeit, wie schlimm ist ein einziges Singleton in der App, etc. pp.

Achso. Dann macht der Verweis auf "Beleidigungen" natürlich Sinn.

 

[Marco13]

Dass der FAQ-Beitrag nicht meiner Interpretation von MVC entspricht, war mir auch mal aufgefallen. Aber wie hier auch schon (und auch schon gaaanz am Anfang) erwähnt wurde: Man hat glaube ich bestimmte Freiheiten. Es macht zwar IMHO keinen Sinn, den Controller Observable zu machen, aber ich denke gerade die Frage, was der Controller ist, hatte ich ja schon anfangs aufgeworfen, und viel mehr als "Hier ist das so", "Ich denke, dass ist so", "Ich habe mal gelesen, dass...", und "Wenn das-und-das so-und-so ist..." kam bisher in diesem Thread für mich nicht rüber. Das Model sollte die View nicht direkt kennen. Viel mehr bleibt (für mich, natürlich, wieder ganz subjektiv ) von MVC damit nicht übrig.

 

[Stefan S.]

Dass der FAQ-Beitrag nicht meiner Interpretation von MVC entspricht, war mir auch mal aufgefallen. Aber wie hier auch schon (und auch schon gaaanz am Anfang) erwähnt wurde: Man hat glaube ich bestimmte Freiheiten. Es macht zwar IMHO keinen Sinn, den Controller Observable zu machen, aber ich denke gerade die Frage, was der Controller ist, hatte ich ja schon anfangs aufgeworfen, und viel mehr als "Hier ist das so", "Ich denke, dass ist so", "Ich habe mal gelesen, dass...", und "Wenn das-und-das so-und-so ist..." kam bisher in diesem Thread für mich nicht rüber. Das Model sollte die View nicht direkt kennen. Viel mehr bleibt (für mich, natürlich, wieder ganz subjektiv ) von MVC damit nicht übrig.

Es gibt bekannterweise unterschiedliche Interpretationen des MVC Musters. Eines steht aber fest, der Controller ist nie der Observable! Den Grund hatte ich bereits oben ausführlich beschrieben.

Der Controller kann aber in einigen Designs auch zum Observer werden, z.B. um bei Änderungen der Daten direkt die View zu manipulieren. Dieser Designansatz wird eher selten verwendet.

Was der Controller ist? Er ist eine Abstraktionsschicht, mit der die Flexibilität gewährleistet wird. Der Controller interpretiert die Eingabe um anschließend das Model auf Basis dieser Eingabe zu manipulieren. Das könnte man natürlich direkt im View-Code machen, aber zum Einen bläht das die View auf, die nun neben der Manipulation der Benutzerschnittstelle auch für die Steuerungslogik des Models zuständig ist und zum Anderen, das ist das Entscheidende, die View wird direkt an das Model gekoppelt. Wenn ich die View nun mit einem anderen Model verwenden will, kann ich das vergessen.

Auch die Steuerungslogik kann ich nun leicht abändern, indem ich einfach den Controller austausche.

Wenn man verstanden hat was MVC ist, dann ist das alles sehr einleuchtend und in keinster Weise kompliziert.

 

[Marco13]

Eines steht aber fest, der Controller ist nie der Observable!

Ja, ist alles eben zu schwammig. Ich hatte ja gesagt, dass mir auch kein Grund einfällt, den Controller Observable zu machen, aber man könnte es... in einem Fall, der auch mit dem Teil zusammenhängt:

...
die View wird direkt an das Model gekoppelt. Wenn ich die View nun mit einem anderen Model verwenden will, kann ich das vergessen.

Ich gehe davon aus, dass das Model in den meisten Fällen ein Interface sein sollte. Und das Interface definiert man nicht zuletzt, um von der Implementierung unabhängig zu sein. Es ist zwar realisitisch (und nicht zuletzt eines der Ziele von MVC) dass man mehrere, ggf. verschiedene Views für dasselbe Modell haben kann, aber dass eine View wirklich verschiedene Modelle darstellen soll, erscheint mir etwas weit hergeholt. Ein JTree zeigt nie ein TableModel an, sondern immer eine Baumstruktur, die durch das Interface TreeModel spezifiziert ist. Ein Slider zeigt keinen Text an, sondern einen Wert in einem bestimmten Bereich, wie es im Interface BoundedRangeModel definiert ist. Das ist eben einfach so. Wenn sich das Modell-Interface ändert, dann ändert das (imho zwangsläufig) auch die View - nach deiner Argumentation müßte man bei einer Änderung des Modells die Änderungen eben (nicht in der View sondern schlicht und einfach) im Controller machen - dass das weniger aufwändig ist, oder dass es erstrebenswert ist, die View beizubehalten, kann ich mir kaum vorstellen. Effektiv würde damit das neue Modell durch den Controller ja nur "umgebogen", so, dass es "aussieht" wie das alte Modell - und da schließt sich der Kreis zum Observablen Controller von oben: Theoretisch (!!!) könnte man natürlich auch den Controller das Modell-Interface implementieren lassen - das Controller könnte (theoretisch!!!) einfach eine Implementierung des Modelles sein, und müßte demnach auch Observable sein. Nur theoretisch - eine sinnvolle Anwendung dafür würde mir spontan nicht einfallen, aber dadurch, dass das Modell nur ein Interface ist, und die View nur dieses Interface kennt (also nicht weiß, dass das, was sie da als Modell sieht, eigentlich der Controller ist) wäre das IMHO zumindest legitim... nicht unbedingt sinnvoll, und irgendwie komisch, aber ... legitim....

 

[Stefan S.]

Ja, ist alles eben zu schwammig. Ich hatte ja gesagt, dass mir auch kein Grund einfällt, den Controller Observable zu machen, aber man könnte es...

Ja, man könnte es. Die Frage ist aber, ob man etwas tut, weil man es tun kann oder ob man es tut, weil es sinnvoll ist. Diese Entscheidung überlasse ich dem Entscheidungsträger.

Ich gehe davon aus, dass das Model in den meisten Fällen ein Interface sein sollte. Und das Interface definiert man nicht zuletzt, um von der Implementierung unabhängig zu sein.

Das ist in der Tat richtig. Wenn das Modell ein Interface ist, ist es prinzipiell stets möglich über das Adapter Muster die Implementierung zu variieren.

Es ist zwar realisitisch (und nicht zuletzt eines der Ziele von MVC) dass man mehrere, ggf. verschiedene Views für dasselbe Modell haben kann, aber dass eine View wirklich verschiedene Modelle darstellen soll, erscheint mir etwas weit hergeholt.

Weit hergeholt ist natürlich subjektiv zu bewerten. Ich hatte schon die ein oder andere Applikation, die verschiedene Modelle darstellte. Natürlich ist eine View das Abbild des Modells und daher in gewissem Maße auch daran gekoppelt.

Wenn sich das Modell-Interface ändert, dann ändert das (imho zwangsläufig) auch die View

Sofern man die Entkoppelung zwischen View und Modell weitestgehend aufrecht erhält, muss die View keineswegs geändert werden, sollte sich das Modell ändern. Wenn man allerdings in der View direkt gegen das Modellinterface programmiert, dann ist das natürlich korrekt.

nach deiner Argumentation müßte man bei einer Änderung des Modells die Änderungen eben (nicht in der View sondern schlicht und einfach) im Controller machen - dass das weniger aufwändig ist, oder dass es erstrebenswert ist, die View beizubehalten, kann ich mir kaum vorstellen.

Ggf. das wir gegen ein interface programmieren, ja. Die Änderungen müssen dann im Controller erfolgen. Ich sagte ja bereits das der Controller eine Kernaufgabe implementiert. Wenn ich den ganzen Kram in die View verschiebe, habe ich zwei Aufgabenbereiche in der View. Abstraktionstechnisch kein guter Ansatz.

Der Trick bei der Sache ist, das ich dank Controller auch gleichzeitig die Steuerungslogik voll austauschbar mache. Programmiere mal ein Spiel und du wirst das zu schätzen wissen.

Wie dem auch sei, es ging in der Diskussion um das Observable. Fällt dir irgendein plausibler Grund ein, den Controller zum Observable zu machen? Mir jedenfalls nicht und bisher habe ich das auch noch nirgendwo sehen können, bis auf diesen ominösen FAQ Eintrag hier.

 

[Wildcard]

Der Controller kann aber in einigen Designs auch zum Observer werden, z.B. um bei Änderungen der Daten direkt die View zu manipulieren. Dieser Designansatz wird eher selten verwendet.

Nicht im geringsten. Bei GEF ist das Standard und es gibt tonnenweise GEF Editoren in the wild. Bei Swing ist es genauso Standard, oder ist ein Renderer ein Observer?

 

[Stefan S.]

Nicht im geringsten. Bei GEF ist das Standard und es gibt tonnenweise GEF Editoren in the wild. Bei Swing ist es genauso Standard, oder ist ein Renderer ein Observer?

Und? Ich hatte bereits darauf hingewiesen das ein Controller auch zum Observer werden kann. Du stimmst mir also zu. Gut!

 

[Wildcard]

Ich sage nur, das diese Form alles andere als selten ist.

 

[Stefan S.]

Ich sage nur, das diese Form alles andere als selten ist.

Ich schrieb "eher selten". Wir hatten doch schon eine Diskussion über absolute Adjektive. Welches Adjektiv soll ich nun deiner Ansicht nach für den Nebensatz verwenden, weniger oder vielleicht mittelmäßig oft?

 

[André Uhres]

Eines steht aber fest, der Controller ist nie der Observable! ...Der Controller interpretiert die Eingabe um anschließend das Model auf Basis dieser Eingabe zu manipulieren.

Frage: wenn der Controller das Model manipuliert, ist es dann nicht sinnvoll für ihn, Observable zu sein, damit er seine Observer über diese Manipulationen direkt informieren kann, also ohne den Umweg über das Model? Bei den Anwendungen, mit denen ich zu tun habe, kann das Model sich eh nicht intern periodisch selbst verändern.

 

[mvitz]

Frage: wenn der Controller das Model manipuliert, ist es dann nicht sinnvoll für ihn, Observable zu sein, damit er seine Observer über diese Manipulationen direkt informieren kann, also ohne den Umweg über das Model? Bei den Anwendungen, mit denen ich zu tun habe, kann das Model sich eh nicht intern periodisch selbst verändern.

Das hatte ich mir auch schon überlegt, aber dann müsste ja jede View, die das Model anzeigen möchte einen Controller haben auch, wenn die View garnichts verändern kann. Ist das Model Observable braucht sie nur das Model kennen.

 

[SlaterB]

die View hat nur einen Listener, ein Interface wie TableModelListener,
welche Klasse den befüttert ist der View egal, bekommt sie auch nicht mit,
die Informationen zur Darstellungsänderung kommen entweder direkt aus dem Event oder aus dem konfigurierten Model der View,
wiederum unabhängig davon, wer das Event sendet

ich sehe keinen 'Umweg', das Model muss eh (vor dem Event) aktualisiert werden, was spielt es für eine Rolle, ob das Model oder der Aufrufer danach die Events losschickt?
interessanter wirds schon, wenn mehrere Stellen das Model ändern können, entweder macht es genau das eine Model, oder jeder Aufrufer muss sich einzeln darum kümmern..

andersrum könnte man vielleicht argumentieren, wenn ein Controller gleich 10 Models ändert und die nicht alle einzeln Events schicken sollen, sondern der Controller das besser koordinieren kann