@Hdi, deine JTable Klasse implementiert das TableModel interface oder wie?
Ja klar. Das TableModel bestimmt welche Daten wie in der Table landen. Voralleme ersteres ist ein Problem, wenn deine Core-Daten das Model selbst ist. Denn was ist wenn du du zB Dateneinträge mit jeweils 5 Attributen hast, diese Table jedoch nur 3 davon anzeigen soll? Ich meine nicht alle internen Daten landen immer in der View. Du kannst in getcolumnCount nicht einfach 3 sagen, wenn dein Business Model == das TableModel, denn damit sind die anderen beiden Attribute auch für alle anderen Stellen deines Programms verschwunden, denn bei dir läuft alles über dieses TableModel. Klar, du kannst ein weiteres TableModel implementieren dass über das erste mappt. Aber genau das mach ich ja, nur dass mein "erstes TalbeModel" halt kein TableModel ist, denn das stimmt nun mal aus Sicht anderer Bereiche in meiner Applikation nicht. Sorry ich hab keine Lust TableDateEvents zu basteln, mit rows und column und so nem Quatsch, wenn ich grad auf absoluter low-level Ebene meine Daten von der Festplatte einlese. Da ruf ich lieber eine einfach addData()-Methode auf meinem Business Model auf, und das weiß intern schon selbst wie es die Daten anordnet.
Und wieso sollte ich irgendwas umimplementieren müssen, nur weil der JTable weg ist kann mein Model immer noch Events werfen. Der JTable hört sie dann halt nicht mehr, die list aber sehr wohl.
Klar, aber wie sinnvoll ist es, irgendwelche TableDateEvents und fire-Methoden mit Angabe von irgendwelchen Row/Column-Indices zu feuern wenn du weit und breit keine Tabelle hast? Das Beispiel von André muss ich zugeben ist ja echt einigermaßen sinnvoll, aber sehr oft kann/will man sich im internen Aufbau der Daten auch nicht unbedingt auf eine tabellarische Anordnung festlegen. Und wie gesagt das heißt noch immer nicht dass man dieses Model überhaupt für ne JTable verwenden kann, wenn die Table nicht alle Infos aus dem Model anzeigen soll.
Sobald die View irgendeinen Typen aus der Domäne kennt und auch noch "manipulative"-Methoden darauf aufruft sind die nicht mehr unabhängig.
Ok, das war dumm gesagt, du hast natürlich Recht. Komplett unabhängig kann View und Model ja nie sein, sonst gäb's keine Kommunikation. Aber die Wahrscheinlichkeit dass sich an der Struktur des Business Models was ändert ist finde ich geringer als die dass ich was an den Views ändern muss. An irgendeiner Stelle musst du immer Anpassungen vornehmen, das Business Model sollte natürlich gut überlegt sein, du kannst ja auch nochmal ein Interface für die manipulativen Methoden drüberklatschen.
Somit ist die Geschäftslogik vollständig von der GUI getrennt, nur umgekehrt muss das nicht gelten. Ist aber imho auch nur in der einen Richtung so wichtig.
Genau, das sehe ich auch so.
