Saubere Architektur mit rel. Datenbanken?

[Eisflamme]

Hi,

Wir basteln gerade an so einem Projekt an der Uni und ich überlege gerade an einer hübschen Architektur, welche mit relationalen Datenbanken arbeiten soll.

Und das finde ich gar nicht so einfach, weil der Bruch zwischen dem nicht-oo DBs und dem klassenbasierten Java (was wir wohl verwenden werden müssen, weil es die einzige Sprache ist, die die meisten können) so eine Sache ist. Wenn ich meine Engine programmiere, habe ich da eine ziemlich saubere Trennung. Würde ich irgendwo etwas speichern wollen, würden die gespeicherten Daten in ihrer Natur vollkommen anders aussehen als im Programm selbst und unser Hauptspeicher sowohl die GPU hält natürlich eine Riesenmasse an Daten. Da ist es klar, dass Speichern/Laden ganz gut ausgelagert werden kann.

Bei betriebswirtschaftlichen Anwendungen ist es aber jetzt ja üblich, dass die Daten im Programm oft 1 : 1 zu den Daten in den DB-Tabellen stehen, wenn man z.B. an Formulare denkt. Also bietet sich ja an, das Klassendesign ähnlich zu gestalten wie die DB-Tabellen selbst.

Hier ein paar Ideen, wie man das alles gestalten könnte:
1) Man bastelt für jede DB-Tabelle eine Klasse. Das habe ich Mal im Betrieb als guten Ansatzpunkt umsetzen sollen. Ich finde es allerdings ziemlich bescheuert, da man hier nichts wirklich kapselt und einen riesigen Overhead erzeugt, quasi eine Schicht, die fast nichts macht. Vorteil ist, dass man auf Änderungen von Tabellennamen oder Attributnamen nur an einer Stelle etwas ändern muss. Aber na ja, dann müsste man streng genommen auch Methodennamen oder den Klassennamen ändern, sodass sich das Problem imo nur verschiebt.

2) Man nutzt globale Methoden oder halt eine Singleton- oder statische Klasse (was immer die SQL-Zugriffs-Klasse bietet, ich hab da noch nich nach Bibliotheken geguckt) und verwendet die einfach lustig, wo man gerade was ändern möchte. Das Klassendesign an sich entspricht dann wohl in etwa den DB-Tabellen (ich gehe jetzt erstmal auch von der Logikschicht aus, die GUI interessiert also noch nicht). Dann hat man irgendwie dickere Klassen, die fast so aussehen wie ein Abbild der DB, aber natürlich nicht 1 : 1 passen. Dieser Unterschied zum 1 : 1 ist dann aber vielleicht verwirrend, weil jemand dadurch versuchen könnte, Analogien zu schließen und dann auf Brüche trifft.

Mehr fällt mir auf Anhieb nicht ein. Wie würdet ihr so was gestalten?

[Chromanoid]

Für objekt/relationales Mapping gibt es einige Frameworks. Hibernate ist eines der bekanntesten Frameworks. Einfach das benutzen und ein TODO auf der Liste abhaken
das ganze liegt in java als Spezifikation vor (die Java Persistence API). Hibernate implementiert diese Spezifikation. Ich kenne mich mit dem Kram nicht aus, aber wenn ihr vor dem Problem steht, solltet ihr euch in das Zeug mal einarbeiten... Wenn man nur die Teile aus der JPA Spezifikation nutzt, kann man Hibernate auch jeder Zeit mit einer anderen JPA Implementation austauschen. Ich weiß nicht ob Java eine Standard Implementation der JPA liefert.

Klassen kann man mit Annotationen so instrumentieren, dass sie in eine relationale Datenbank gespeichert werden können. Wie das genau mit Abfragen und so aussieht weiß ich leider nicht...

PS: wenn ihr nicht Java oder .Net einsetzt, gibt es sicherlich andere Frameworks für C++ oder andere Sprachen. http://www.google.com/search?q=object+p ... ce+C%2B%2B

[Eisflamme]

Ich würde auch lieber eine vernün... C++ nutzen, aber das kann außer mir halt keiner. :<

Hibernate schaue ich mir Mal an, danke. Dennoch würde mich interessieren, wie man selbst eine schöne Architektur bastelt bzw. was so üblich ist, wenn man eben kein Framework nutzt. :)

[Chromanoid]

Ich würde Java für eine solche Aufgabe immer vorziehen. C++ Entwicklung frisst meiner Meinung nach immer ein bisschen mehr Zeit, wenn es sich um komplexe Aufgaben handelt, die den Einsatz von vielen Bibliotheken erfordern. Aber das ist nur meine Meinung.
Aber da du ja sowieso Java einsetzen musst :):
Ich würde JPA einsetzen, weil es State-of-the-Art ist und wenn du mal ein Projekt in einem Unternehmen entwickeln musst, ist genau so ein Framework, das was langfristig Zeit und damit Geld spart. Derartige Mapping-Frameworks sind AFAIK Industriestandard und es würde einfach nur Zeit kosten etwas eigenes zu entwickeln. IMO solltest du deine Zeit lieber in das Kennenlernen dieser Technologien stecken anstatt den langen steinigen unfruchtbaren Weg zu gehen ;). Genau so ein Framework ist ja das Resultat von Überlegungen wie deiner und im Grunde die Best-Practice Lösung, die sich viele Experten ausgedacht haben. Wenn du also das Framework verstehst, kennst du die Antwort auf deine Überlegungen :D.

Annotationen wären auch für eine eigene Lösung sehr cool ^^. So sieht das mit JPA aus:

Code: Alles auswählen

@Entity
public class Address {
  @Id
  protected long id
  String street1;
  String street2;
  String city;
  String province;
  @Embedded
  ZipCode zipCode;
  String country;
...
}

Schau mal hier: http://download.oracle.com/javaee/6/tut ... bnbpz.html

[Eisflamme]

Also ich hab ehrlich gesagt eher bei Java mit neuen Frameworks Schwierigkeiten, weil da immer irgendwas nicht läuft. :P Bei C++ bau ich irgendwas rein, dann gibt's ggf. Linkerfehler. Wenn man das aber gelöst hat, läuft's oft auch. Aber sind halt meine persönlichen Erfahrungen, ich bin kein Java-Spezialist.

Auch ist die Programmierumgebung semi-groß, sag ich Mal. Die Einarbeitung in das Framework ist ja auch wieder Einarbeitung, während man das Projekt sicherlich "Quick'n'Dirty" schon schnell programmieren könnte. Es soll nur etwas schöner sein. :) Und soweit ich jetzt über die JPA geschaut habe, ist das schon viel Einarbeitungszeit. Ich würde sagen, dass sich das nicht unbedingt lohnt. Es ist halt "nur" ein Projekt für ein Semester (d.h. bei mir 3 Monate) und hat keine sehr hohe Priorität, es wird wöchentlich dran gearbeitet. Wir sind 10 Leute und an Mannstunden haben wir dann vll. ... 1000? Allerhöchstens 1000.

Also ich schau mir das definitiv Mal an. Vll. gibt's ja noch andere Vorschläge. Meine Ausgangsfrage nach Architektur erscheint mir dann doch nicht als schlechter Ansatzpunkt. :)

Edit: Ok, das Team hat das Ding abgelehnt. Es hat keiner Lust auf EE. Also schließen wir Frameworks mal besser aus und nach wie vor steht die Frage im Raum, wie man so was am besten bastelt. ;)

[pUnkOuter]

Wenn du nicht gross Vererbung mit abstrakten Klassen einsetzt, kann man das relativ leicht selbst machen, einfach eine Tabelle für jede Klasse und Assoziationen entweder als Fremdschlüssel, wenn 1 zu 1 oder als Zwischentabelle, wenn n zu n. Dann musst du noch schauen, dass die Typen einiger Felder richtig konvertiert werden, und gut ist.

Ich empfehle aber auch ein Framework einzusetzen. Besonders Hibernate ist in der Profi-Welt gerade extrem gefragt, da kann es nie schaden, bereits etwas Erfahrung damit gesammelt zu haben.

[Eisflamme]

Ja... aber es sprengt halt eben den Rahmen um Längen. Und die meisten sind nicht Mal in Java besonders fit.

Wir werden jetzt wohl einfach pro Tabelle ne Zugriffsklasse basteln und gut ist. Nicht der Weisheits letzter Schluss, aber immerhin einfach und sollte genug laufen.

[Hanno]

Wenn Hibernate zu komplex ist, dann probier's vieleicht mal mit BeanKeeper.
Lange her, dass ich mich damit beschäftigt habe, aber es machte damals einen ganz guten Eindruck auf mich.

Ist die relationale Datenbank eine feste Anforderung? Falls nicht, wäre evt. eine objektorientierte Datenbank passender. Ich habe vor 2-3 Jahren mit NeoDatis sehr gute Erfahrungen gemacht.

[Eisflamme]

BeanKeeper sieht für mich ganz gut aus, da es auch sehr einfach ist. Aber wie gesagt: Framework ist raus.

Und oo DB ist natürlich sehr interessant, aber jetzt auch wieder zu viel Aufwand. Das ist kein Ein-Mann-Projekt, sondern da müssen sich dann 10 Leute einarbeiten. Einfach irgendeine SQL-Klasse zu nehmen und alles selbst zu coden, macht zwar gewissen Aufwand, reicht aber für das Projekt aus, und insgesamt verlieren wir dadurch weniger Mannstunden, daher rechnet sich imo nichts Neues. Ein, zwei Gedanken zur Architektur sind da einfacher.

Aber wie gesagt, die Lösung ist im Grunde ja gefunden.

[hagbard]

Warum eigentlich keine abstrakte Basisklasse für den Zugriff auf Tabellen die dann nur unterschiedlich ausgepprägt werden muss?

Weil ich denke mal die meisten Operationen werden bei jeder Tabelle ähnlich sein (Get,Search,Write...).

[Hanno]

Und oo DB ist natürlich sehr interessant, aber jetzt auch wieder zu viel Aufwand. Das ist kein Ein-Mann-Projekt, sondern da müssen sich dann 10 Leute einarbeiten.

NeoDatis ist ziemlich einfach. Schau dir mal das 5-minute-tutorial an: http://www.neodatis.org/5m-tutorial
Der Einstieg dürfte einfacher sein als mit einer SQL-basierten Lösung.

Aber ich will dir nichts aufschwatzen, insbesondere wenn du dich schon für eine Lösung entschieden hast. Ich will nur vermeiden, dass du einen falschen Eindruck hast.

[Eisflamme]

Na ja, meine Entscheidung war das nie, ich dachte nur, ich frage Mal wo nach, wo sich Leute auskennen. :) Link hab ich in unsrem Chan gepostet und drauf hingewiesen, vll finden die Gefallen dran. Für mich sieht das wirklich auch ziemlich einfach aus. Danke :)

[Eisflamme]

Hm... Ich hab mir das jetzt nochmal angeschaut. Es scheint so etwas wie JOINs zu geben, aber das kommt erst ganz am Ende der Doku. Hast Du das denn schon Mal für komplexere Relationen versucht? Wir haben bei uns halt 6-7 Tabellen/Klassen, die in einem Pfad liegen. D.h. über Klasse 1 finde ich Zeug über Klasse 7 heraus evtl. Lässt sich so was damit ohne Probleme umsetzen?

Der Vorteil von dem Ding ist ja, dass man es nahtlos integrieren kann. Der Nachteil ist, dass die Auswechselbarkeit nicht gegeben ist: wenn wir irgendwann sehen, dass das Ding nicht alles unterstützt, haben wir Pech gehabt oder wir müssen alles umstrukturieren in eine relationale DB...

[odenter]

Vielleicht wäre das hier das richtige:
http://hfx.sourceforge.net/

Warum eigentlich keine abstrakte Basisklasse für den Zugriff auf Tabellen die dann nur unterschiedlich ausgepprägt werden muss?
Weil ich denke mal die meisten Operationen werden bei jeder Tabelle ähnlich sein (Get,Search,Write...).

Natürlich sind die Operationen in jeder Tabelle ähnlich (SELECT, INSERT, UPDATE, DELETE).
Aber wenn Du das machst, dann mixt Du lustig Daten mit Anwendungs-Logik. Ganz böse Sache, also besser trennen.

Am Beispiel von Adressen baust Du dir ein Objekt das den Adressdatensatz im Speicher hält.
Also im Grunde nur eine dämliche Klasse mit vielen Feldern und Set-/Get-Methoden. Dann brauchste nur noch einen Server oder Proxy und der bekommt ein Adressenobjekt. Das ist wichtig weil es ja sein könnte das Aktionen beim speichern/laden einer Adresse auch Aktionen in einer anderen Tabelle auslösen die Du nicht mit Triggern realisieren willst oder kannst. (Stichwort scripting, events)
In dem Proxy oder Server wird also erstmal die Logik zum laden, verändern und speichern verpackt.

Das wäre erstmal so das simpelste, kann man dann auch beliebig einfach erweitern, das nächste wäre dann ein ConnectionPool, Undo/Redo-Funktionen, lazy loading, etc.
Letztlich machen auch alle Frameworks mehr oder weniger genau das.

Du kannst natürlich auch die Nummer mit dem "eigenen Datenobjekt" sein lassen und ne Basisklasse die den kompletten Record darstellt und dann Get-/Set-Methoden hat um auf die Felder zuzugreifen, wäre dann zwar noch simpler, allerdings bekommst Du dann später Probleme wenn Du doch mal vor bzw. nach dem ändern eines bestimmten Wertes/Feldes bestimmte Aktionen starten willst.

[hagbard]

@odcenter
Ich bin kein DB-Spezialist aber wenn ich es "sauber" machen müsste würde ich den kompletten Zugriff auf die Datenbank durch eine Art Interface Server Applikation realisieren (welche die abstrakte Basisklasse benutzt und ausprägt) und das somit trennen. Das geht glaube in die selbe Richtung die du vorschlägst.
Aber der Opener wollte ja eher eine quick'n'dirty Lösung :D Vielleicht meldet er sich ja mal wieder und sagt uns welcher Weg zum Erfolg geführt hat. ;)

[Eisflamme]

Quick'n'Dirty und eigene Architektur schließen sich nicht aus, auch wenn viel in diesem Thread darauf hindeutet, dass das hier einige so sehen.

Das Projekt wird erst in ein paar Monaten starten und ich werde die Architektur nicht leiten, da ich Java nicht mag. Ich schreibe dann Mal, wie wir's machen werden. Vermutlich einfach für jede Tabelle eine Klasse mit statischen Methoden oder so ein Müll.