@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.
