Darstellung von großen Tabellen in Client/Server o.a. 3 Tier-Archetektur

takidoso

takidoso

Erfahrenes Mitglied
Hallo allesammt,

Ich habe folgende Problemstellung:
Innerhalb einer Client/Server-Architektur sind Tabellen mit imens vielen Zeilen auf dem Client darzustellen. Eine sehr einfache Idee ist natürlich alle Zeilen zu lesen und in der Tabelle des Clients anzuzeigen. Dumm nur ist, dass Initialisierung und Refresh für den Client verflucht lange dauern. Ein viel versprechender Ansatz ist dem Client nur einen Teil der eigentlichen Tabellenzeilen für die Anzeige zur Verfügung zu stellen, so dass die Leitung nicht mit allen Zeilen der Tabelle belastet wird. Dabei ergeben sich andererseits natürlich weitere Anforderungen auf den Serverteil der Anwendung. Denn möchte ein User z.B. die Tabelle nach seinen Vorstellungen sortieren, müsste dies der Server übernehmen und den aktuell anzuzeigenden Ausschnitt der Gesammtdatenmenge an den Client senden, - man möchte ja nicht nur den gerade aktuellen Ausschnitt, sondern sämtliche Zeilen sortiert wissen. Das ganze soll natürlich multiuserfähig sein, also das sortieren von einem User soll natürlich nicht die Sortierung der Tabellenzeilen anderer Anwender beeinflussen.

Meine Frage: Hat irgendjemand schon einmal dieses Problem gehabt und gelöst, am besten natürlich in einer sehr allgemeinen Weise so dass man Klassen nicht mehr anpassen sondern nur noch parametrieseien braucht?

mit zwischenjährlichen Grüßen

Takidoso
 
Thomas Darimont hat gesagt.:
Hallo!

Zu diesem Problem gibt es ein J2EE Designmuster:

Value List Handler:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ValueListHandler.html

Das hier könnte vielleicht auch recht nützlich sein:
http://www.tutorials.de/tutorials180818.html&highlight=oracle

Gruß Tom
Zum Vergrößern anklicken....

Hi Tom,
vielen Dank erstmal für die beiden Links. Leider ist der erste mir einfach zu EJB-lastig. Selbst arbeite ich mit Apache-SOAP-RPCs, gewöhnlichem JDBC und Swing. Ich gebe zu etwas faul zu sein, hatte ich doch gehofft, jemanden zu finden, der schon mal auf die Idee gekommen ist, so etwas mehr oder weniger generisch anzustellen.
Dies war gewissermaßen meine persönliche "Marktforschung" :-)
Ich hatte mal zu diesem Thema eine gute Seite gefunden die eine Art rudimentäres Framework darstellte, allerdings an manchen Sachen noch etwas unvollständig, z.B. ist in dem Beispiel keine DB-Anbindung sondern ein fester Beispiel-Datenpool und es geht offenbar nur für read-only Darstellungen.
Für mich stellt sich die Frage, ob es sinnvoll ist vieles über die neuartigeren JDBC-2 zu bauen oder doch lieber was eigenes zu basteln, so dass weniger die DB angesprochen werden würde, andererseits sämmtliche Daten auf dem Server-Teil gehalten werden müssten.
Der erste Ansatz erscheint mir vielleicht riskant wegen Performance zu sein, da mir nicht so klar ist wie, auf welche weise und wann etwas bei JDBC-2 gecached bzw. die DB erneut angefragt wird. Zusätzlich müsste ich mir die Connections der eingeloggten User immer merken um entsprechend den aktuellen Ausschitt halten zu können, ab einer gewissen Anzahl wird das wohl nicht Zweckmäßig sein. Beim 2. Ansatz hat man alles selbst unter Kontrolle, andererseits bedeutet er einen Haufen Daten auf dem Server-Teil zu halten und eine etwas längere Initialisirungsphase auf selbigem. Sortierungen z.B. würde ich je nach Anfrage ebenso cachen. In anderen Worten ich bastele eine Art spezialisierte DB nach. Ein weiterer Grund es vielleicht mit der 2. Variante zu versuchen ist, dass es unabhängig von JDBC sein könnte.

Welches der beiden Übel würdest Du wählen, Tom? Weiß vielleicht jemand, ob JDO oder ähnliche Verfahren da Kochrezepte oder gar Implementiertes als Alternative bereithalten?

Naja ich melde mich vielleicht, wenn es bei mir klappt und stelle vielleicht die Lösung mal vor, sofern ich soweit komme.

Gruß

Takidoso

PS: hier erst einmal der Link der mich dazu inspirierte
http://www.javaworld.com/javaworld/javatips/jw-javatip137.html
Leider geht es hierbei nur um read-only-tables
 
Hallo!

Hast du dir in dem zusammenhang schon mal SwingSet angeschaut?
http://swingset.sourceforge.net/
Dort findet man eine Reihe von Swing Komponenten die in der Art von Borlands DBSwing schon ne DB Kopplung integriert haben.

Weiterhin zu deiner Frage ob man noch mit JDBC 2 herumhantieren sollte bzw. ob man in dieser Beziehung doch besser mit was Handgestrickten fährt... ich denke sowas lohnt sich nicht mehr. Heute gibt es so viele tolle und gute JDBC Abstraction Layer (wie etwa http://www.ibatis.com/ ) die einem die Arbeit mit JDBC erleichtern und bzw. zu großen Teilen sogar abnehmen. Schau mal dort nach vielleicht findest du damit ja auch direkt schon eine Lösung für deine "ausschnittsweise" Anzeige von Tabellendaten. Btw. schau mal hier -> http://www.ibatis.com/common/example.html

Wegen dem Sortierproblem würde sich folgendes (vielleicht) anbeiten.

Wenn's denn extrem viele Daten sind die jedoch oft nach einem ganz bestimmten Muster sortiert sein sollen könntest du doch Views auf die Tabellen legen die du dann je nach gewünschtem Kriterium schon "vorsortierst".

HTH,

Gruß Tom
 
Hi Tom,
vielen Dank für Deine Recherche. Ich habe mal bei dem ibatis via email nachgefragt, ob ein solches Feature in ihrem Framwork drin ist. swingset, befürchte ich kommt bei mir nicht in Frage, da es offenbar rein Client/DB-Server mäßig zu geht. Dies ist bei DBSwing z.B. auch der Fall ein Grund warum ich es nicht nutze, zumal es vor noch 3-4 Jahren gnadenlose Fehler beinhaltete.
Und Fehler kann ich besser nachvollziehen und verbessern, wenn ich selbst Meister des Frameworks bin :-)
Andererseits wundert es mich schon, dass eine solche Problematik, die ja sicher recht häufig vorkommen dürfte, von keinem Framework direkt bzw vollständig angegangen zu werden scheint, zumindest wenn man die Featurelisten durchgeht. EJB hält zwar eine "Vorgehensweise" bereit, aber die habe ich auch, ob mit oder ohne EJB. Naja vieleicht bekomme ich ja von den Leuten von IBATIS eine zufriedenstellende Möglichkeit dargelegt.

bis die Tage

Takidoso
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück