Datenbankzugriff - Best Way - Datasets oder Klassen ?

[HeinzJ]

Ich bin gerade dabei eine neue Applikation (Client / MSSQLSERVER) zu entwerfen und überlege, was der beste Weg sein könnte für den Datenbankzugriff

1. Klassen + Queries ?
2. Custom Dataset (wg. Caching) + Klassen + Queries ?
3. nur Datasets

Ich habe immer wieder die Java Beans im Hinterkopf und frage mich, wieso diese so stark benutzt werden. Delphi kenne ich bisher nur stark Dataset-lastig. Datasets sind schön einfach zu verwenden .... Mhhh

Wer kann mir bei all dem Für und Wieder weiterhelfen. Ein paar weiterführende Links wären auch hilfreich.

Grüße, HeinzJ

[Hansa]

Zitat von HeinzJ:

..Delphi kenne ich bisher nur stark Dataset-lastig..

Wieso soll das eine Last sein ? Das ist ein Vorteil, weil so ziemlich alles darauf aufgebaut ist. Ausnahme : Exoten und BDE. Die Frage widerpricht sich ausserdem noch. Denn worauf soll denn eine Klasse überhaupt aufgebaut sein ?

[HeinzJ]

...lastig... war nicht wertend gemeint. Sollte nur heißen das die einen großen Raum einnehmen. Konzepte wie z.B. Beans finden sich dagegen kaum.

[Hansa]

Du hast die Delphi-Version nicht angegeben. Sofern das keine Demo ist, bzw. Personal usw. dann hilft ein Blick in den VCL-Quelltext. Und was sieht man da ? Das TDataSet hat viele als virtual; deklarierte Methoden. Im Prinzip initialisieren sie also lediglich irgendwas, bzw. verhindern abstrakte Fehler durch fehlende Prozedur-Rümpfe. TDataSet ist jedenfalls eigentlich leer. Die eigentlichen Funktionen werden von den daraus abgeleiteten konkreten Zugriffskomponten erledigt. Insofern gibt es auch kein TCustomDataSet, weil im TDataSet sowieso alles definiert werden muss.

[Ralf Kaiser]

Zitat von HeinzJ:

...lastig... war nicht wertend gemeint. Sollte nur heißen das die einen großen Raum einnehmen. Konzepte wie z.B. Beans finden sich dagegen kaum.

Was unterscheidet denn eine Java-Bean von einer Delphiklasse (bzw. spezieller: einer Delphi-Komponente)??

Eine Java-Bean ist doch eine normale Klasse die sich an gewisse Konventionen bei den Zugriffen auf die Eigenschaften hält (hauptsächlich damit IDEs damit umgehen können). Somit sind eigentlich alle Delphi-Komponenten im Grunde so etwas wie Beans.

Ich kann mich auch irren. Bitte korrigier mich wenns falsch ist...

EDIT: oh, das war gerade Beitrag Nummer $FF

[Der_Unwissende]

Zitat von HeinzJ:

Konzepte wie z.B. Beans finden sich dagegen kaum.

Hm, ist ein wenig wie Äpfel mit Bohnen vergleichen
Java verfolgt natürlich ein ganz anderes Konzept als Delphi. In Java findest Du einfach eine starke Verwendung bestimmter Muster, z.B. das DAO Pattern. Die Beans können dabei einfach gut als Transfer Object eingesetzt werden. An sich hat eine Java Bean aber wirklich wenige Eigenschaften (die Namenskonvention wurde schon genannt, zudem sind alle afaik serialisierbar). Anders gesagt, Bohnen werden dort nur als Container für die Daten eingesetzt.
Ganz wichtig ist dabei, dass man nochmal die Java Enterprise Beans davon getrennt betrachtet. Auch dort gibt es halt Konzepte, wie man auf ein DBS zugreift, jedoch haben Enterprise Beans jeweils ganz bestimmte Rollen. Das Konzept kann man super bei Sun nachlesen (ist etwas umfangreicher), an sich erlaubt dort jedenfalls der Einsatz dieser speziellen Beans eine sehr weitreichende Verwaltung durch den Enterprise Server (z.B. kümmert dieser sich komplett selbst um die Nebenläufigkeit).

Jedenfalls wurden die Beans in Java als ein spezielles Element entwickelt, mit einer festen Aufgabe. Dieses Konzept kommt also aus der Java Welt und wurde für ihre Ansprüche entwickelt. Solche Konzepte werden in der Regel nicht einfach auf andere Plattformen übertragen (bzw. es gibt einfach schon bessere Alternativen).

[HeinzJ]

Wie oben schon erwähnt, habe auch ich bisher hauptsächlich immer nur die Datasets benutzt.
Ich habe auch gerade eine intensive Beschäftigung mit Mustern und Java hinter mir und versuche momentan gerade das mit meinem bisherigem Delphi Know how zusammenzubringen bzw. die Java- und Pattern- Konzepte in Delphi wiederzufinden sowie die Vor-und Nachteile herauszufinden. Ich habe dementsprechend auch schon viel in Delphi ausprobiert . Dazu gehört UML (Together, Modelmaker), ORM, InstantObjects u.v.a. Auch hier im Forum finden sich entsprechende "Beanchen" (Dynamisch erzeugte Datenmodule)
Mittlerweile raucht mir auch der Kopf schon dementsprechend
Daher meine Frage nach dem "Best Way" hinsichtlich der Datenbankprogrammierung.

HeinzJ

[Der_Unwissende]

Design Pattern sind so eine Sache für sich, die kannst Du völlig unabhängig von der tatsächlichen Programmiersprache einsetzen. Der größte Vorteil, den Design Pattern bieten ist eine durchdachte Architektur. Ein Pattern dokumentiert bereits, welches Problem es zu lösen gilt und auf welche Art und Weise die Lösung erfolgt (und ganz wichtig, auch warum!).
Pattern bieten Dir damit einfach die Möglichkeit, dass Du auf vorhandenes Wissen zurückgreifst. Mögliche Risiken sind eben einfach schon bekannt, ebenso wie ein Lösungsweg usw. Der Einsatz von Pattern lohnt sich also immer (auch wenn einem nicht immer klar ist, wo man diese schon längst verwendet).

[alzaimar]

HeinzJ, ich hatte neulich eine ähnliche Diskussion.

Ich würde das mal vereinfacht so beantworten:

1. Schreibst du eine kleine Desktop-Anwendung, nimm die TDBEdits, TDatasources und TxxxQuery Komponenten und klick Dir die Anwendung zusammen. Das sollte für einfache(!) Anwendung ausreichen. Eine der Hauptvorteile von Delphi ist ja RAD und so geht das am schnellsten.

2. Schreibst Du eine komplexere Anwendung oder eine mit mehreren Clients, dann solltest Du das OR-Modell wählen. Deiner Mittelschicht spendierst Du eine schöne Schnittstelle, die einfach die logischen Datensätze (z.B. Kunde) aus der DB zusammensammelt, hübsch serialisiert und dem Client als 'Objekt' zuschickt. Der Client verändert dann das Objekt und schickt es zurück. Die Mittelschicht kümmert sich dann ums Abspeichern.

Listen und Auswertungen (Auftrags- Kundenübersichten) dagegen würde ich so nicht implementieren. Da würde ich mir doch ein TDataset gönnen und irgendwie (entweder über die Mittelschicht oder direkt) die DB anzapfen. Ich habe mit Objektlisten performancetechnisch einfach keine guten Erfahrungen gemacht...

[HeinzJ]

Zitat von Der_Unwissende:

Der größte Vorteil, den Design Pattern bieten ist eine durchdachte Architektur

Richtig. Ich finde aber leider immer nur zeilenlastige Beispiele im Java Bereich. Beispiele in denen Datasets auftauchen sind nicht vorhanden.

Zitat von alzaimar:

Listen und Auswertungen [...] dagegen würde ich so nicht implementieren. Da würde ich mir doch ein TDataset gönnen

Mit solch einem Design hatte ich auch schon mal angefangen. Ich fand aber die Anbindung an diverse gute Grid-Komponeneten einigermaßen unbequem und ging dann dazu über neben Klassen (auch für Listen) ebenfalls auch noch Datasets zu verwenden. So ganz sauber isses dann aber nicht geworden. Ich hatte dann neben diversen Listen Datasets mit sehr ähnlichen Inhalten.

HeinzJ