Model View Controller

[Gelöschtes Mitglied 65838]

Also ich verstehe das Grund Prinzip vom Model View Controller

Ich hab meine View mit den GUI Elementen
[CODE lang="java" title="View"]class View{
Button = new Button("hi")
methode getButton
}[/CODE]
mein Model mit der Logik
[CODE lang="java" title="Model"]class Model{
String = "Hallo Welt";
methode getString
}[/CODE]
und meinen Controller der die verbindet

class Controller{
    this.view
    this.model
        
    view.getButton.onAction -> Sysout(model.getString)
}

So jetzt erstmal bin ich bei diesem verständnis schon mal auf einem Richtigen weg

dann Zweitens:
wie behandelt man hier den Code wenn zb die View dynamisch erweitert wird

bei mir scheitert es immer dran dass die Ganzen Klassen teile von Model und view haben

und dann noch zu den Pakcages wie kann man die so aufteilen dass es noch verwaltbar ist...

ich habe bei meinem Programm 5 Views ergo dann 15 klassen aufwärts in einem Package da blick ich nicht mehr durch

 

[Robert Zenz]

Du musst sie ja nicht im gleichen Paket lagern. Ganz im Gegenteil, es macht Sinn diese in getrennten Paketen zu halten. Der grosze Vorteil von MVC ist an und fuer sich dass man die Geschaeftslogik von der Praesentation getrennt hat, zumindest in der Theorie ist es dann sehr leicht moeglich einfach eine andere Oberflaeche zu verwenden. Wenn du also jetzt von der Logik und der Praesentation als austauschbare und erweiterbare Teile denkst, macht es mehr Sinn diese in einem anderem Paket zu halten.

Dass Java-Models schnell sehr grosz werden, liegt nunmal in der Natur der Sache. Wenn du Fuenf unterschiedliche Entitaeten hast, wirst du Fuenf Klassen brauchen. Es gibt auch andere Ansaetze, einen davon hat das JVx Framework, in welchem man DataBooks hat welche aehnlich zu einer Map funktionieren und direkt auf eine Datenbank greifen. Der Vorteil ist dass man sich eben ein groszes Java Model spart und man immer mit dem Model der Datenbank arbeitet. Der Nachteil ist dass man die Typ-Sicherheit beim kompilieren verliert. Der Ansatz hat aber insbesondere Vorteile wenn man in eine bestehende Datenbank greifen will.

So oder so, es gibt immer Leute die den Boilerplate versuchen verzweifelt zu vermeiden welcher mit einem Java Model einhergeht (Getter, Setter und so weiter), aber man muss sich hier immer vor Augen fuehren dass es sich dabei nicht um Komplexitaet handelt. Wenn du 100k Zeilen POJOs hast die nur aus Gettern und Settern bestehen, ist das absolut Erdnuesse im Vergleich zu einem 10k Zeilen Projekt welches einen eigenen Web- und Datenbankserver implementiert, zusammen mit einem Compiler-Plugin um Klassen zu generieren. Verwechsle hier also nicht "das ist aber viel Code" mit "das ist aber schwierig zu handhaben", nur weil etwas eine grosze Code-Basis ist, bedeutet nicht dass das Projekt unwartbar ist. Absolut nicht. Die wichtige Frage ist wieviel Komplexitaet in dem Projekt steckt, und das ist beim Model vernchlaessigbar wenn es nur POJOs sind.

Zu guter letzt, wenn dein Model waechst, kannst du es natuerlich noch in weitere Pakete teilen. Nehmen wir mal an du haettest ein ERP System mit POS Anbindung. Dann koenntest du das Model aufteilen in:

• YOURAPP.model.inventory.articles
• YOURAPP.model.inventory.storage
• YOURAPP.model.customers
• YOURAPP.model.employees

Und so weiter. EIn gutes Prinzip welches man hier aber immer beachten sollte ist, dass du nie versuchen solltest eine "saubere" Trennung zu erzwingen. Mache nur das was Sinn macht. Fuenf Model Klassen wuerde ich nicht aufteilen, das zahlt sich absolut nicht aus. View und Controller abzutrennen hingegen macht sehr wohl Sinn.

 

[Gelöschtes Mitglied 65838]

und wie behandelt man eine Dynamische gui im MVC gibts da ein Beispiel dafür

 

[Robert Zenz]

Also um noch kurz nachzusetzen. Wenn du es als Uebung machst, waere vermutlich die einfache Aufteilung:

• YOURAPP.controller.*
• YOURAPP.model.*
• YOURAPP.view.*

Durchaus ein guter Ansatz. Die Pakete wuerde man in einem "richtigen" Projekt vermutlich anders nennen, zum Beispiel "gui", "backend", "logic" und aehnliches. Wenn du dann weiter "ueben" willst, kannst du ja diese weiter unterteilen, zum Beispiel wenn du Zwei Oberflaechen haben willst:

• YOURAPP.view.javafx
• YOURAPP.view.swing

und wie behandelt man eine Dynamische gui im MVC gibts da ein Beispiel dafür

Was meinst du mit "dynamisch" in dem Zusammenhang?

 

[Gelöschtes Mitglied 65838]

Also um noch kurz nachzusetzen. Wenn du es als Uebung machst, waere vermutlich die einfache Aufteilung:

• YOURAPP.controller.*
• YOURAPP.model.*
• YOURAPP.view.*

Durchaus ein guter Ansatz. Die Pakete wuerde man in einem "richtigen" Projekt vermutlich anders nennen, zum Beispiel "gui", "backend", "logic" und aehnliches. Wenn du dann weiter "ueben" willst, kannst du ja diese weiter unterteilen, zum Beispiel wenn du Zwei Oberflaechen haben willst:

• YOURAPP.view.javafx
• YOURAPP.view.swing

Was meinst du mit "dynamisch" in dem Zusammenhang?

ich füge im nachhinein durch events nodes hinzu dann müsste die view es wissen dass ein node gekommen ist und die View muss dann dem node den eventhanlder geben

 

[Robert Zenz]

Entweder die GUI weisz wann sie sich neu zeichnen muss, beziehungsweise sich neue Daten holen muss, zum Beispiel wenn der "Speichern" Knopf gedrueckt wurde. Oder du hast ein "aktives Model", welches die GUI notifiziert sobald sich etwas daran geaendert hat. Ein Beispiel dafuer sind die Bereits genannten DataBooks aus JVx, welches fuer jede Aenderungen Events feuern. Ein anderes gutes Beispiel dafuer ist die JavaFX ObservableList, welche ebenfalls Events feuert sobald sich die Liste geaendert hat.

Erstere Ansatz reicht vermutlich vollkommen aus wenn immer nur ueber die GUI gearbeitet wird. Weil dort weisz man ja wann der Benutzer etwas getan hat, und ob sich diese Aktion auf die Daten auswirkt oder nicht. Das wuerde fuer den Anfang auf jeden Fall reichen.

 

[Gelöschtes Mitglied 65838]

Hab ich das jetzt so richtig eingeteilt oder bin ich da immer noch aufm Holzweg

 

[Robert Zenz]

Ja, vom Prinzip her wuerde ich das auch so machen. Eventuell waere es noch interessant die Postfixe von den Klassen wegzulassen, da dir ja bereits das Paket (und meistens der Kontext) bereits sagt worum es geht. Aber das ist dann Geschmackssache und eine Kleinigkeit.