nicht angemeldet
Vorteil MVC
Gunnar BittersmannHallo Forum,
schönes Wochenende Euch allen.
Ich habe mir heute diese Seite durchgelesen:
http://leepoint.net/notes-java/GUI/structure/40mvc.html
1. Beim Controller habe ich zum ersten Mal gesehen, dass man innerhalb einer Klasse auch neue eigenständige (Unterklassen?) erstellen kann?
2. Meine Hauptfrage, da ich letztes in diesem Thread versucht hatte die allgemeine Struktur von Klassen zu erlernen, wie nun genau der Vorteil der oberen MVC aussieht?
Man hätte jetzt ganz blöd ausgedrückt, in der Klasse "view" ja schon ein "Model" erstellen können und bräuchte im main-programm nicht einmal model und view erzeugen. Ich frage mich nun, wie es grob aussehen würde, wenn ich das Aussehen des Calculators oder anstatt Multiply eine andere Rechnung integrieren/verändern wurde, denn mit MVC sollte das ja nun praktisch/unaufwändig gehandhabt werden
3. Wie war denn das nochmal, wenn ich vom Main-Programm oder einer anderen Klasse auf eine statische Klassenvariable zugreife? Klassenname.VARIABLENNAME="Wertzuweisung" (Wenn sie nicht Final ist)
Grüße
-
Hi!
- Beim Controller habe ich zum ersten Mal gesehen, dass man innerhalb einer Klasse auch neue eigenständige (Unterklassen?) erstellen kann?
Hat aber nichts mit dem Controller zu tun, dass man private Klassen anlegen kann.
- Meine Hauptfrage, da ich letztes in diesem Thread versucht hatte die allgemeine Struktur von Klassen zu erlernen, wie nun genau der Vorteil der oberen MVC aussieht?
MVC ist eine Methode, die Zuständigkeiten zu trennen. Es geht dabei immer darum, modulare Programmteile zu haben, die in sich abgeschlossen eine Aufgabe erfüllen. Man kann sie dann unter Beibehaltung der bestehenden Schnittstellen intern umschreiben, ohne die jeweils anderen Teile zu betrachten. Man kann beispielsweise bei gleicher Geschäftslogik (im Model) die View ändern, um die Daten für ein anderes Ausgabemedium anders formatiert auszugeben.
Man braucht dazu nicht unbedingt das MVC-Pattern, aber es ist eben eine von vielen Möglichkeit, um komplexe Anforderungen übersichtlich in Code zu strukturieren.
Man hätte jetzt ganz blöd ausgedrückt, in der Klasse "view" ja schon ein "Model" erstellen können und bräuchte im main-programm nicht einmal model und view erzeugen. Ich frage mich nun, wie es grob aussehen würde, wenn ich das Aussehen des Calculators oder anstatt Multiply eine andere Rechnung integrieren/verändern wurde, denn mit MVC sollte das ja nun praktisch/unaufwändig gehandhabt werden
Solange sich die View weiterverwenden lässt, brauchst du das Model nur um weitere Funktionen zu erweitern oder schreibst bei grundlegend verschiedenen Aufgaben ein neues. Dem Controller eine weitere Action hinzufügen und fertig ist die neue Funktionalität (sehr vereinfacht dargestellt).
Lo!
-
hi,
Man hätte jetzt ganz blöd ausgedrückt, in der Klasse "view" ja schon ein "Model" erstellen können und bräuchte im main-programm nicht einmal model und view erzeugen. Ich frage mich nun, wie es grob aussehen würde, wenn ich das Aussehen des Calculators oder anstatt Multiply eine andere Rechnung integrieren/verändern wurde, denn mit MVC sollte das ja nun praktisch/unaufwändig gehandhabt werden
Solange sich die View weiterverwenden lässt, brauchst du das Model nur um weitere Funktionen zu erweitern oder schreibst bei grundlegend verschiedenen Aufgaben ein neues. Dem Controller eine weitere Action hinzufügen und fertig ist die neue Funktionalität (sehr vereinfacht dargestellt).
Nehmen wir an, ich mach eine neue Funktion "Wurzel" anstatt Multiply und will die View behalten.
1. Ich erweitere das Model (bei komplexeren Sachen evtl. neue Klasse) um die die Methode public void wurzel (String d) {//Führe die Wurzel aus}
2. Im Controller mache ich dann einen WurzelListener der dann die spezielle wurzel-Methoden von Model aufruft.
Und jetzt kommts, wenn ich das Verstanden ist es abgehakt.
a) Ich müsste praktisch die View auch abändern, da der Knopf nicht mehr "Multiply" heißt, sondern Wurzel? Dazu könnte ich aber sicherlich im Controller den Namen des Knopfs übergeben. Wobei ich dann das Gefühl habe, dass alles nun anfängt ineinander hineinzufriemeln?
b) Meinen Main-Programm müsste ich dann auch anders aufrufen, damit der Controller weiß, welchen Listener er auswählen muss. Einfach einen Zusatzparameter mitgeben beim Erzeugen?
Grüße
-
Hi!
a) Ich müsste praktisch die View auch abändern, da der Knopf nicht mehr "Multiply" heißt, sondern Wurzel? Dazu könnte ich aber sicherlich im Controller den Namen des Knopfs übergeben. Wobei ich dann das Gefühl habe, dass alles nun anfängt ineinander hineinzufriemeln?
Wie immer führen mehrere Wege nach Rom. Du kannst einerseits eine neue auf Wurzelziehen angepasste View erstellen. Oder du übergibst einer generischen View alles was sie wissen muss, auch die Beschriftung der Buttons und die Methode, die beim Knopfdruck zurückgerufen werden muss.
b) Meinen Main-Programm müsste ich dann auch anders aufrufen, damit der Controller weiß, welchen Listener er auswählen muss. Einfach einen Zusatzparameter mitgeben beim Erzeugen?
Ja, wie auch immer du zwischen den Rechenarten umschaltest, der Controller muss irgendwie davon erfahren. So ein Pattern legt nicht fest, wie genau die Implementation erfolgen muss. Das kannst du halten wie du willst. Letzlich muss deine Erfahrung den Ausschlag geben, wie sich etwas am besten implementieren lässt.
Lo!
-
Hi dedlfix,
a) Ich müsste praktisch die View auch abändern, da der Knopf nicht mehr "Multiply" heißt, sondern Wurzel? Dazu könnte ich aber sicherlich im Controller den Namen des Knopfs übergeben. Wobei ich dann das Gefühl habe, dass alles nun anfängt ineinander hineinzufriemeln?
Wie immer führen mehrere Wege nach Rom. Du kannst einerseits eine neue auf Wurzelziehen angepasste View erstellen. Oder du übergibst einer generischen View alles was sie wissen muss, auch die Beschriftung der Buttons und die Methode, die beim Knopfdruck zurückgerufen werden muss.
b) Meinen Main-Programm müsste ich dann auch anders aufrufen, damit der Controller weiß, welchen Listener er auswählen muss. Einfach einen Zusatzparameter mitgeben beim Erzeugen?
Ja, wie auch immer du zwischen den Rechenarten umschaltest, der Controller muss irgendwie davon erfahren. So ein Pattern legt nicht fest, wie genau die Implementation erfolgen muss. Das kannst du halten wie du willst. Letzlich muss deine Erfahrung den Ausschlag geben, wie sich etwas am besten implementieren lässt.
vielen dank. jetzt habe ich mal endlich was verstanden und der thread zieht sich nicht so hin :-))))
Meine größte Sorge ist das ganze Zeugs mit Interfaces, Ableitungen usw. wie in dem anderen Thread damals von mir, aber dazu will ich mich erst einmal noch etwas einlesen und poste dann dazu später.
-
-
-
Moin!
Ich habe mir heute diese Seite durchgelesen:
http://leepoint.net/notes-java/GUI/structure/40mvc.htmlDie Darstellung von MVC dort befasst sich mit der Anwendung für den Fall einer Applikation.
MVC im Kontext "Web" sieht deutlich anders aus.
Beiden Fällen gemeinsam ist aber, dass mit "Model - View - Controller" die drei Gebiete abgegrenzt werden, die man aufgrund der Trennung von Zuständigkeiten (und zur Erlangung von Unabhängigkeit) beachten will:
Model: Alles, was mit dem Bereithalten, Heranholen oder Abspeichern von Daten zu tun hat.
View: Die Präsentation der Daten - dem Benutzer, oder irgendwelchen anderen Services.
Controller: Die Schaltstelle. Welche Benutzerinteraktion auf welchem View sorgt für welche Datenoperation mit den Model? Und wie kommt das Ergebnis dann wieder woanders hin?
- Meine Hauptfrage, da ich letztes in diesem Thread versucht hatte die allgemeine Struktur von Klassen zu erlernen, wie nun genau der Vorteil der oberen MVC aussieht?
Trennung von Zuständigkeiten erlaubt in der Regel höhere Flexibilität bzw. geringere Auswirkungen bei Änderungswünschen. Wenn ein View eine bestimmte Anordnung von Bedienelementen hat, kann man diese einfach ändern, ohne dass im Controller die Anwendungslogik beeinflusst wird, oder im Model die Datenhaltung.
Ich weise aber noch mal darauf hin, dass MVC sich in Zusammenhang mit Desktop-Applikationen sehr anders auswirkt, als im Zusammenhang mit browserbasierten Webapplikationen. Dieses Forum hier beschäftigt sich primär mit letzterem. :)
- Sven Rautenberg
-
Hi,
MVC im Kontext "Web" sieht deutlich anders aus.
Ich weise aber noch mal darauf hin, dass MVC sich in Zusammenhang mit Desktop-Applikationen sehr anders auswirkt, als im Zusammenhang mit browserbasierten Webapplikationen. Dieses Forum hier beschäftigt sich primär mit letzterem. :)
Bevor ich versuche an dem MVC Beispiel mir eine Erweiterung/Änderung auszudenken meine Frage. Inwiefern unterscheidet sich dies im Bereich web-applikation, denn mein Augenmerk wird später auch im Webbereich liegen. Die groben/konkreten Unterschiede?
Grüße
-
Hi!
Bevor ich versuche an dem MVC Beispiel mir eine Erweiterung/Änderung auszudenken meine Frage. Inwiefern unterscheidet sich dies im Bereich web-applikation, denn mein Augenmerk wird später auch im Webbereich liegen. Die groben/konkreten Unterschiede?
Im Web hast du einen Request, den du abarbeitest und fertig ist die Laube. Dabei erzeugt die View nur eine Ausgabe. Bei einer Desktopanwendung läuft selbige die gesamte Zeit, und die View muss auf Ereignisse der Oberfläche reagieren und die Anwendung benachrichtigen. Deswegen hantiert das Beispiel mit Listenern, damit die View dem Controller darüber was sagen kann.
Lo!
-
Hi Lo!,
Im Web hast du einen Request, den du abarbeitest und fertig ist die Laube. Dabei erzeugt die View nur eine Ausgabe. Bei einer Desktopanwendung läuft selbige die gesamte Zeit, und die View muss auf Ereignisse der Oberfläche reagieren und die Anwendung benachrichtigen. Deswegen hantiert das Beispiel mit Listenern, damit die View dem Controller darüber was sagen kann.
ahja, oki, vielen Dank.
Ich mache mir dann nur noch kurz Gedanken zum Erweitern/Ändern poste dies und denke, dass wir dann das Thema abschließen können, bzw. ich einen guten Überblick mir erschafft habe.Grüße
-
@@dedlfix:
nuqneH
Im Web hast du einen Request, den du abarbeitest und fertig ist die Laube. Dabei erzeugt die View nur eine Ausgabe.
Kann man so nicht sagen. Es ist auch eine Anwendung denkbar, bei der Model, View und Controller komplett clientseitig (JavaScript) laufen.
Nutzerinteraktionen führen zu Änderungen der Daten auf dem Client. Am Ende schickt der Nutzer die Ausgabe zum Drucker, per E-Mail irgendwohin oder meinentwegen auch per HTTP an irgendeinen Webserver.
Das kommt einer Desktopanwendung nahe. Sehr nahe:
Bei einer Desktopanwendung läuft selbige die gesamte Zeit, und die View muss auf Ereignisse der Oberfläche reagieren und die Anwendung benachrichtigen. Deswegen hantiert das Beispiel mit Listenern, damit die View dem Controller darüber was sagen kann.
Qapla'
--
Volumen einer Pizza mit Radius z und Dicke a: pi z z a
-
-
-
hi,
Trennung von Zuständigkeiten erlaubt in der Regel höhere Flexibilität bzw. geringere Auswirkungen bei Änderungswünschen. Wenn ein View eine bestimmte Anordnung von Bedienelementen hat, kann man diese einfach ändern, ohne dass im Controller die Anwendungslogik beeinflusst wird, oder im Model die Datenhaltung.
würde man in diesem Beispiel für eine andere/zweit(neue) Anordnung eine neue View-Klasse erzeugen oder würde man innerhalb der view einen anderen Konstruktor oder anderen Methoden zur Platzierung machen?
-
Hallo,
- Beim Controller habe ich zum ersten Mal gesehen, dass man innerhalb einer Klasse auch neue eigenständige (Unterklassen?) erstellen kann?
Ja. Das kann sinnvoll sein, wenn die Unterklasse (oder das "Unter-Interface") in einem so engen Bezug zur "Hauptklasse" (bzw. dem Interface) steht, dass sie ohne diese überhaupt keinen Sinn machen würde.
Im Java-Sprachumfang gibt es dazu diverse Beispiele, z.b.
ein einzelnes Schlüssel-Wert-Paar in einer Map:
Ein Schlüssel-/Wertpaar ausserhalb seines Kontextes "Map" zu betrachten, macht keinen Sinn, deswegen ist das Interface "Entry" ein Teil des Interfaces "Map".Man hätte jetzt ganz blöd ausgedrückt, in der Klasse "view" ja schon ein "Model" erstellen können und bräuchte im main-programm nicht einmal model und view erzeugen.
...und dann das Model auch nochmal neu programmieren müssen, wenn man mal Präesentation verändern bzw. neu machen will :)
Wie schon die Vorredner beschrieben haben, die Trennung von Model, View und Controller erlaubt, dass Datenhaltung/Repräsentation, Logik und Präsentation unabhängig voneinander sind, sodass diese jeweils für sich ausgetauscht werden können.
Nicht immer ist das sinnvoll, z.b. wenn die Anwendungslogik in einem so erheblichen Maß von der Art der Datenhaltung abhängt, dass dies nicht getrennt werden kann. Deswegen gibt es auch Abwandlungen des MVC-Musters, bei denen einzelne Komponenten zusammengezogen werden.
Umgekehrt gibt es auch Fälle, in denen es sinnvoll sein kann, die einzelnen Schichten weiter zu unterteilen, z.b. das Model in einer System-abhängigen (z.b. konkrete Anbindung an eine MySQL-Datenbank) und system-unabhängigen Schicht (z.b. Klassen zum erzeugen/updaten/löschen von Objekten UNABHÄNGIG von der darunterliegenden Persistenzschickt) zu realisieren.- Wie war denn das nochmal, wenn ich vom Main-Programm oder einer anderen Klasse auf eine statische Klassenvariable zugreife?
Klassenname.VARIABLENNAME="Wertzuweisung" (Wenn sie nicht Final ist)
Auf Variablen sollte man von aussen nach Möglichkeit über Setter zugreifen.
Davon aber mal abgesehen, dürfte sich durch die von Dir geschriebene Anweisung die statische Variable entsprechend verändern, alle Instanzen der Klasse, die mit dieser Variable umgehen, würden künftig den neuen Wert nehmen, genauso auch andere Klassen, die die statische Variable auslesen.Viele Grüße,
Jörg-
Hi,
- Beim Controller habe ich zum ersten Mal gesehen, dass man innerhalb einer Klasse auch neue eigenständige (Unterklassen?) erstellen kann?
Ja. Das kann sinnvoll sein, wenn die Unterklasse (oder das "Unter-Interface") in einem so engen Bezug zur "Hauptklasse" (bzw. dem Interface) steht, dass sie ohne diese überhaupt keinen Sinn machen würde.
in einem Interface kann man auch private Unterklassen einfügen??
Morgen schaue ich mir nochmal genau meinen alten Thread an bzgl. des Veständnisse:
http://forum.de.selfhtml.org/archiv/2009/12/t193735/#m1294396Grüße