Der Ball ist rund, Teil 3: Entwicklung eines Tippspiels in Java

Das Runde muss ins Eckige

Thilo Frotscher

Nachdem in den beiden vorangegangenen Teilen der Artikelserie zunächst architektonische Überlegungen angestellt und dann die Realisierung der Präsentationsschicht beleuchtet wurde, geht es dieses Mal um die immer wiederkehrende Frage, mit welcher Technologie der objektrelationale Sprung beim Zugriff auf die Datenbank am besten gemeistert werden kann. Hierzu werden die wichtigsten zur Wahl stehenden Alternativen vorgestellt, um anschließend die Umsetzung im Tippspiel-Projekt anhand der gewählten Technologie zu erläutern.

Die Wahl einer geeigneten Persistenztechnologie zählt zu den wichtigsten und kritischsten Entscheidungen während der Entwicklung von Anwendungen. Wird an dieser Stelle ein falscher Weg eingeschlagen, kann der Datenzugriff leicht zu einem Flaschenhals werden, was natürlich den Erfolg des gesamten Projektes gefährdet. Doch es ist nicht einfach, den Überblick über die unterschiedlichen zur Wahl stehenden Technologien zu behalten. So gilt es zunächst, einen der verschiedenen prinzipiellen Ansätze auszuwählen, von denen an dieser Stelle drei betrachtet werden sollen: JDBC, CMP und JDO.Zunächst gibt es natürlich die offensichtliche Möglichkeit, mithilfe von JDBC die gesamte Persistenzlogik selbst zu programmieren. In der Regel wird man dabei Datenzugriffs- oder Persistenzschichten entwickeln, die im Idealfall derart gestaltet werden, dass sie auch für andere Anwendungen und Projekte wieder verwendet werden können und auch dann noch funktionieren, wenn einmal das verwendete Datenbankprodukt gewechselt wird. Dabei wird der Entwicklungsaufwand aber anfangs in aller Regel umso größer, je generischer die Persistenzschicht sein soll. Immerhin: Hat man diese Aufgabe gut gelöst, kann man im Falle ihrer Wiederverwendung im nächsten Projekt eine ganze Menge Arbeit sparen. Doch dieses Rad muss nicht unbedingt immer neu erfunden werden. Stattdessen kann für eine solche Persistenzschicht auch auf eine bereits bestehende Lösung zurückgegriffen werden. Hierzu stehen verschiedene objektrelationale Mapping-Lösungen wie etwa Hibernate [1] oder TopLink [2] zur Verfügung. Diese sollen jedoch im weiteren Verlauf des Artikels nicht weiter betrachtet werden.Der zweite Ansatz besteht in der Verwendung von CMP, der Container Managed Persistence von Entity Beans, bei der sich der EJB Container quasi automatisch um die Datenbankkommunikation kümmert. In diesem Zusammenhang sollte jedoch unbedingt geklärt werden, ob der Einsatz von Enterprise JavaBeans für die zu entwickelnde Anwendung überhaupt sinnvoll ist. In der Vergangenheit endeten zahlreiche Projekte unerfolgreich oder zumindest mit gehöriger Enttäuschung, weil Enterprise JavaBeans verwendet wurden. Sehr häufig wurde dann angeführt, dass die entwickelten Anwendungen viel zu langsam seien. Dabei ist deutlich zu unterstreichen, dass Enterprise JavaBeans als Technologie nicht etwa prinzipiell abzulehnen sind. Aber die Lösung muss eben auch immer zum Problem passen und der Einsatz von Enterprise JavaBeans eignet sich beispielsweise denkbar schlecht für kleine bis mittlere Projekte mit nur geringer Last, bei denen Skalierbarkeit und verteilte Transaktionen keine bzw. eine eher untergeordnete Rolle spielen. Es ist also wichtig, sich über diese grundsätzliche Fragestellung zunächst eingehende Gedanken zu machen.Als dritter Ansatz geht mit JDO (Java Data Objects) ein vergleichsweise recht junger Kandidat ins Rennen. JDO ist nicht auf eine bestimmte Implementierungstechnologie wie Enterprise JavaBeans beschränkt und könnte prinzipiell auf jeder Anwendungsschicht zum Einsatz kommen. JDO hat gerade in jüngster Vergangenheit eine große Fangemeinde gewonnen, die sich nicht zuletzt auch aus vielen früheren Anhängern von CMP zusammensetzt.

Abb. 3: Architektur des Tippspiel-Projektes
Geschrieben von
Thilo Frotscher
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.