Abspeichern eines kompletten JPanels

[Gast2]

ICh muss hdi absolut recht geben. Seine Ausführungen bezüglich der Festlegung auf einen JTable waren genau der Grund wieso ich das Business Model angesprochen hatte. Auch wenn das TableModel schon ein Model ist so legt man sich fest.

Man kann bei Wechsel der Anzeigeart natürlich sein Model anpassen, aber ist das wirklich sinnvoll?

Unabhängig davon geht der TO auf diese Thematik sowieso nicht ein sondern versucht einfach nach wie vor alles aus der GUI zu serialisieren.

 

[ThreadPool]

[...]
Die einzelnen Views haben eine Referenz auf das Business-Model, und rufen dort entsprechende manipulative Methoden auf.
[...]
Sowohl die einzelnen Views, als auch die gesamte business-Schicht sind vollständig unabhängig voneinander.[...]

Letzteres kann so nicht stimmen wenn Ersteres gilt. Sobald die View irgendeinen Typen aus der Domäne kennt und auch noch "manipulative"-Methoden darauf aufruft sind die nicht mehr unabhängig.

Übrigens durch solche Gedankengänge wer wen kennen und wer mit wem über was kommunizieren soll sind reichlich Variationen bezgl. MVC entstanden und irgendwie gibt es immer Anwendungen in denen man die eine oder andere Variation bevorzugen kann.

 

[Gast2]

Übrigens durch solche Gedankengänge wer wen kennen und wer mit wem über was kommunizieren soll sind reichlich Variationen bezgl. MVC entstanden und irgendwie gibt es immer Anwendungen in denen man die eine oder andere Variation bevorzugen kann.

Stimmt, jedoch sollte in jedem Fall die Business Logik == Model nichts von der GUI wissen! Die GUI kennt ja zumindest den Controller bzw. direkt das Model. Sei es als INterface.

Nutzt man als Controller z.B. ein Binding Framework muss ja irgendwer binden. Macht das keine eigene Klasse die sowohl View als auch Model kennt tuts meistens die GUI selbst.

In jedem Fall kennt dann das Model aber die GUI und den Controller (in dem Fall das Framework) nicht.

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. Die GUI muss sich ja ohnehin an den Inhalten der Model orientieren.

 

[Nachtfalke]

Da der Thread nun ziemlich weit von der ursprüngliche Frage in die Programmierphilosophie weggedriftet ist, kann er von mir aus geschlossen werden. Die Vorschläge, die bezüglich des ursprünglichen Problems gefallen sind, sind alle interessant, würden in meinem Fall aber ein Redesign der Anwendung erfordern. Dafür ist mir der Aufwand zu hoch. Ich war davon ausgegangen, daß ich die angezeigten Objekte per Serialisierung relativ aufwandsarm speichern und wiederherstellen könnte. Anscheinend geht das nicht.

 

[Gast2]

[OT]

Da der Thread nun ziemlich weit von der ursprüngliche Frage in die Programmierphilosophie weggedriftet ist

Nur so am Rande, das ist keine Philosophie sondern Best Practise...
Das du nun nicht redesignen kannst/magst versteh ich schon. Das kommt nunmal vor.[/OT]

 

[hdi]

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

 

[bERt0r]

Ich bin ja ganz bei dir, dass das Business Model von der GUI getrennt sein sollte, aber das trifft nunmal nur zu, wenn du überhaupt eines brauchst. Dein Businessmodel ist in Wirklichkeit nichts anderes als ein TableModel marke Eigenbau, bei dem du halt alles selber spezifizierst. Weil für jede View die du hinzufügst, musst du ja eine eigene View Komponente schreiben, die dann dein Model-Interface implementiert.
Man kann auch in einem Tablemodel die set und get-Methoden überschreiben, und die eigentliche Datenhaltung auslagern, z.B an einen DB-Manager.
Mir scheint es geht hier einfach um den Unterschied: Wiederverwendbarkeit in anderen Anwendungen vs Anpassung der Anwendung an andere Anforderungen.

 

[hdi]

Verstehe ich alles. Ich finde nur wenn du ein TableModel nimmst und dann anfängst alles so umzuleiten und zu overriden dass es am Ende eigentlich gar keins mehr ist, dann kannst du dir ja gleich was ganz eigenes schreiben. Und egal wie du es implementierst, der Name "TableModel" bleibt, was an sich schon eine implizite Aussage hat wie ich finde, und die sollte auch zutreffen. Ich meine, du erbst ja auch nicht von ArrayList und machst daraus ein Set, oder?

Aber ich glaub wir können das hier langsam zu Grabe tragen. Ich hab inzwischen verstanden was du bzw André meinen, und ich kann das in Teilen nachvollziehen. Ich persönlich versuche mir einfach aus Prinzip an gewisse Design-Regeln zu halten, auch wenn das vllt in manchen Fällen Overkill ist, was ich ja durchaus zugebe. Ist mir aber einfach lieber.