MVC - Verständnisfrage

[hklaudia]

Hallo!

Ich habe grad begonnen mit der Erstellung meines ersten Projekts. Und zwar möchte ich ein Java-Programm entwickeln indem man einen Gitarrengriff (nach Namen) wählen kann, dieser wird dann angezeigt (wie man ihn hält) mit der Option ihn abzuspielen. Zusätzlich kann man einen neuen Gitarrengriff hinzufügen (Datenbank) und aufnehmen.
Ich hab jetzt von meinem Projekt-Leiter die Aufgabe bekommen ein UseCase Diagramm zuerstellen (erledigt) und die Architektur des Programms zu entwerfen, dabei hat er mir die MVC-Architektur vorgeschlagen. Ich soll das grafisch entwerfen. Irgendwo soll ich auch noch unterbringen auf welchem Betriebssystem das laufen soll usw.
Und hier steh ich nun vor einem Problem. Ich versteh nicht genau wie ich das alles entwerfen soll?!
Vielleicht kann mir jemand mit einem Ansatz weiterhelfen.

lg,
Klaudia???

 

[bone2]

schonmal basics gelesen?

Model View Controller ? Wikipedia

 

[hklaudi]

ja schon..ich weiß nur nicht ob ich es richtig verstehe. und zwar.. in die view kommt die swing oberfläche rein. in das controll kommen meine funktionen rein also zb griff wählen, abspielen.. und model ?? und womit hängt die db zusammen?

 

[Camino]

Das Model enthält die Daten. Du kannst z.B. deine Daten aus der Datenbank ins Model holen und das aktualisiert dann die View.

 

[xote]

Ich versuche es mal zu erklären (hoffentlich auch richtig):

View:
Die View ist das Swing-Zeugs, z.B. JPanel oder JFrame, richtig, aber es steht nicht drin, wie die View aussieht (Framegrößen, Farben, etc.) sondern welche Programmdaten die View gerade anzeigen soll, also z.B. welche Einträge gerade in der Liste dargestellt werden, die die Benutzer anzeigt. Diese Daten bekommt die View vom Modell - und zwar jedes Mal wenn das Model geändert wird, deswegen nimmt man da normalerweise dieses Observer/Observable-Zeugs. Normalerweise gibt die View Ereignisse wie einen Klick an den Controller weiter, muss also unter Umständen sehr wohl z.B. einen ActionListener spielen. Es ist also natürlich nicht so, dass die View keine Aktionen machen soll. Sie soll halt nicht das Model direkt ändern.

Controller:
Der bekommt die Ereignisse der View und ändert entsprechend das Model.

Model:
Hier könnte jetzt drin sein, welche Benutzer es (zur Zeit) gibt, um beim Beispiel der Liste mit den Benutzern zu bleiben. Wenn man darüber nachdenkt, was Observer und Observable heisst, dann weiss man auch was davon das Model sein muss (natürlich Observable), und was die View (Observer).

und womit hängt die db zusammen?

Ich würds so machen: wenn man eine bestimmte Schaltfläche klickt, dann geht dieses Ereignis an den Controller und der ändert die DB entsprechend - und da du den MVC Ansatz verwenden willst wahrscheinlich auch das Model.

Irgendwo soll ich auch noch unterbringen auf welchem Betriebssystem das laufen soll usw.

Und ich Idiot dachte immer JAVA wäre plattform-unabhängig...

Ohne Gewähr...

 

[hklaudia]

danke, ich denke ich habs mittlerweile viel besser verstanden und nun meine frage ob ich das so richtig vor habe zu implementieren:

view: ist halt die oberfläche mit swing, wo auch meine gitarrengriffe gezeichnet werden, meine buttons usw.

controller: hier wird von der vier zb mein "griff wählen" aus der view weiter ans model gegeben und wieder zurück. also kommen hier die actionlistener rein.

model: hier sind dann meine methoden, wie zb griffWaehlen().., griffAbspielen()..

und jetzt meine frage noch.. ich denk für dieses programm reicht mir im model eine klasse, weil ich nur die usecases griff wählen, abspielen, aufnehmen und hinzufügen hab. und ich werde mit der JavaDB arbeiten, wo ich dann die griffe abspeichere. diese db auch in der gleichen klasse rein? oder soll das in eine eigene klasse?!

wenn ich iwo einen verständnisfehler habe, dann bitte um aufklärung ^^

und zu dem "Und ich Idiot dachte immer JAVA wäre plattform-unabhängig..." jaa..aber wir sollen in der doku schreiben, auf welchem betriebssystem es gemacht wurde..

 

[Mindstream]

danke, ich denke ich habs mittlerweile viel besser verstanden und nun meine frage ob ich das so richtig vor habe zu implementieren:

view: ist halt die oberfläche mit swing, wo auch meine gitarrengriffe gezeichnet werden, meine buttons usw.

controller: hier wird von der vier zb mein "griff wählen" aus der view weiter ans model gegeben und wieder zurück. also kommen hier die actionlistener rein.

model: hier sind dann meine methoden, wie zb griffWaehlen().., griffAbspielen()..

und jetzt meine frage noch.. ich denk für dieses programm reicht mir im model eine klasse, weil ich nur die usecases griff wählen, abspielen, aufnehmen und hinzufügen hab. und ich werde mit der JavaDB arbeiten, wo ich dann die griffe abspeichere. diese db auch in der gleichen klasse rein? oder soll das in eine eigene klasse?!

wenn ich iwo einen verständnisfehler habe, dann bitte um aufklärung ^^

und zu dem "Und ich Idiot dachte immer JAVA wäre plattform-unabhängig..." jaa..aber wir sollen in der doku schreiben, auf welchem betriebssystem es gemacht wurde..

Als Modell würde ich in deinem Fall die Datenbank betrachten. Diese solltest du in deinem Programm als ein Objekt darstellen. Z.B.

class DB:
  load()
  save()

Falls du lediglich einen View planst reicht eine einfache Implementierung des MVC aus:

class Controller:
  Controller(db):
    this.db = db
  setView(view):
    this.view = view
  handleActions(event):
    if event.action == save:
      db.save(event.music)
    if event.action == load:
      view.showTitle(db.load(event.musicURL))
      view.showLength(db.load(event.musicURL))
class View:
  View():
    buttons = createButtons() // Buttons mit Gitarrengriffen, load/save Button
  setController(newController):
    buttons.unsetActionHandler(this.controller) //Für alle buttons
    this.controller = newController
    buttons.setActionHandler(controller) //Für alle buttons
view = new View()
controller = new Controller(new DB())
controller.setView(view)

Ansonsten sollte DB ein Observerable sein und jeder View ein Observer, sodass bei einer Veränderung der Modells alle Views genotified werden. Dazu musst du für jeden View db.register(view) und view.setModel(DB) aufrufen.
Ein Szenario wäre dass du Musik Dateien in deinem MusikEditorView abspeicherst und zusätzlich noch einen MusicCollectionView für die gespeicherten Dateien hast. Dann würde der MusikEditor beim Speichern dem Controller bescheid geben. Der Controller sagt "DB.save(newMusic)" und die DB sagt "an alle views: guckt mal bei mir nach ob es neue Musik gibt". Und MusicCollectionView hört das, holt sich die aktuell gespeicherte musik, lädt diese direkt mit musicList = DB.getList() und aktualisiert seine Liste auf dem Bildschirm.

PS: Der Pseudocode ist in Python Syntax verfasst (Einrückungen statt Klammern), allerdings ohne def s bei dem Methoden, die ja sowieso durch die Klammern gekennzeichnet sind.

MindStream

 

[hklaudia]

ok also die db als mein model. in der gleichen klasse auch meine methoden für wählen..abspielen usw?
und ja habe vor nur eine view zu haben

 

[Gast2]

Du brauchst wenn du eine DB hast mehrer Schichten siehe
Schichtenarchitektur ? Wikipedia
MVC liegt nur in der Päsentationschicht und ist ein GUI Paradigma und hat erstmal nix mit einer DB zu tun.

 

[Mindstream]

@SirWayne:
>>Du brauchst wenn du eine DB hast mehrer Schichten
Schichten sind nur eine sehr grobe Ansicht auf ein System; Das MVC bietet hingegen eine wesentlich feinere Auflösung für die Implementierung
>>MVC liegt nur in der Päsentationschicht
Das kommt darauf an wie man die Schichten einteilt. In diesem Fall kann man durchaus die Views der Päsentationschicht, den Controller der Mittelschicht und die DB dem Backend zuordnen, womit man eine 3 Schichten Architektur hat. Dann hat man eine schicke Übersichtsgrafik..
>>und ist ein GUI Paradigma
MVC ist genau genommen ein Architektur Muster, welches durch bekannte Zusammensetzungen von Software Design Pattern realisiert werden kann. Das Pattern ist aus einer Bibliothek in der Programmiersprache Smalltalk bekannt, welche für die Erstellung von GUIs gedacht ist. Das heißt aber nicht, dass es nur ein GUI Paradigma ist.
>>und hat erstmal nix mit einer DB zu tun.
Das Modell stellt einen Datenspeicher dar. Das kommt der Bezeichnung einer Datenbank schon Mal nahe.


Das wiedergeben der Musik Dateien würde ich dem MVC zufolge direkt in den Views realisieren da man es als Darstellung der Daten im Modell interpretieren kann. Eine andere Darstellung wäre z.B. die Datei als Frequenzdiagramm darzustellen. Das sähe dann etwa so aus:
1. Klick auf Play Button im View löst Play Action aus
2. Controller wird informiert und
2a) holt die entsprechende Datei vom Modell
2b) befiehlt: view.play(datei)
2c) befiehlt: view.display("now playing "+datei.getName())
Ich kann dir empfehlen deine Use Case Diagramme in solche Use Case Texte umzuwandeln. Die Diagramme sind eher dazu gedacht mit dem Kunden zu kommunizieren. Für den Programmierer sind sie eher unbrauchbar. Aus den Use Case Texten lässt sich mit etwas Übung leicht ein Sequenzdiagramm erstellen aus dem sich dann bereits eine Grobe Struktur für das Programm ergibt.
Denke einfach daran, dass der Use Case irgendwo anfangen muss (bei dir vermutlich mit einem Mausklick auf den View). Dann muss die Nachricht zum Controller geleitet werden, der dann wie ein König dem Modell und dem View befiehlt was sie daraufhin machen sollen, ohne dass er dabei selbst etwas machen muss.
Das wählen einer Datei beeinflusst das Modell vermutlich nicht. D.h.,
1. Wählen der Datei auf View löst eine Aktion aus
2. Controller erhält Nachricht und sagt if event=="wählen": View.wähle(event.dateiname)
Irgendwie bekloppt, aber du kannst dir vorstellen dass ein anderer Controller dadurch das Verhalten der Views völlig verändern kann. Z.B. könntest du beim View einen Controller setzen, der einfach nichts macht. Und schon hättest du einen Read-Only View.
Btw., der View wäre bei dir das Oberste graphische Element, dass die darunterliegenden Schaltflächen etc. enthält, also z.B. eine Unterklasse von Frame.

Ich stehe der Design Entscheidung das MVC in deinem Fall zu verwenden kritisch gegenüber. Es verkompliziert das Programm möglicherweise ohne sichtbare Vorteile. Ich sehe es als Anwendung des Indirection GRASP Patterns, bei dem Anfragen durch ein intermediäres Objekt (hier Controller) an die eigentlichen Objekte weiterleitet werden. Das ist eine gute Sache, wenn du komplexe Views und ein komplexes Modell hast und es oft veränderst/weiterentwickelst, da meistens lediglich der Controller angepasst werden muss. Der Controller ist dabei meistens relativ einfach gestrikt, da die eigentlichen Aufgaben (Datenbank Kommunikation+Wiedergabe/Anzeige von Dateien) von Modell und View geleistet werden. Deshalb ist der Controller einfach anpassbar.
Dagegen spricht aber, dass es in einem kleinen Programm einfacher ist Modell und View anzupassen, da sie nicht wesentlich komplizierter sind als der Controller. Hierbei sprechen z.B die GRASP Pattern High Cohesion, Low Coupling, sowie Information Expert dafür, dass das Modell die Daten Darstellt, weil es die Daten Kapselt.

Du solltest also abwägen wie komplex dein Programm wird und ob es sich die zusätzliche Komplexität des MVC lohnt. Genau genommen hast du schon Mal eine Verbindung (zwischen View und Modell) weniger als beim MVC, weil du nur einen View hast. Damit sparst du zumindes einen Teil der Komplexität ein.

 

[Gast2]

@
>>MVC liegt nur in der Päsentationschicht
Das kommt darauf an wie man die Schichten einteilt. In diesem Fall kann man durchaus die Views der Päsentationschicht, den Controller der Mittelschicht und die DB dem Backend zuordnen, womit man eine 3 Schichten Architektur hat. Dann hat man eine schicke Übersichtsgrafik..

Diese Diskussion hatten wir hier schon mal. MVC ist ein Architektur Muster für die Präsentationschicht und ist nicht auf mehreren Schichten anzusehen.


Aber mei keine Luschd schon wieder darüber zu disktuieren...

 

[Mindstream]

Diese Diskussion hatten wir hier schon mal. MVC ist ein Architektur Muster für die Präsentationschicht und ist nicht auf mehreren Schichten anzusehen.


Aber mei keine Luschd schon wieder darüber zu disktuieren...

Das würde glaube ich auch zu weit vom Thema abweichen. Ich habe mir Mal ein paar der Threads und den Wiki Artikel durchgelesen und habe gemerkt, dass du von einer Infrastruktur Architektur ausgehst. Deswegen stimme ich deinen Aussagen zu. Ich hatte an eine Software Architekturen gedacht, in der es auch Schichten geben kann, die sich z.B. um Persistenz/Logik/Darstellung kümmern. Mein Fehler, dass ich deinen Link nicht berücksichtigt habe.
Es überrascht mich, dass du bei dem Thema auf die Infrastruktur eingehst, weil ich den Zweck dafür nicht sehe.

 

[bERt0r]

Critical Technology: MVC in a three-tier architecture