Datenbankanwendung und Klassen - sinnvoll?

[DeddyH]

Könnten wir uns nicht einfach darauf einigen, dass OOP-Kenntnisse für ein ORM elementar sind?

[MrSpock]

Zitat von DeddyH:

Könnten wir uns nicht einfach darauf einigen, dass OOP-Kenntnisse für ein ORM elementar sind?

Ich glaube schon.

Ich habe mein Studium 1988 abgeschlossen. Da war das funktionale Zerlegen eines Problemfeldes angesagt. Meine Diplomarbeit ist ein umfangreiches Programm gewesen, in dem ich die Funktionale Zerlegung sehr gut umgesetzt habe. Aber schon damals hat mich gestört, dass Daten nicht so "sauber" behandelt wurde. Als dann OOP aufkam und ich auch viel darüber gelesen hatte, hat es dennoch fast 2 Jahre gebraucht, bis ich den Paradigmenwechsel auch wirklich vollzogen habe. Ich habe einfach bei Problemlösungen nicht in Objekten, ihren Eigenschaften und Methoden gedacht, sondern anfangs nur in Funktionen. Man muss nämlich bereits ganz früh im Design in Objekten denken.

Aber auch ein anderer Aspekt hat mich damals wie hier in der Fragestellung beschäftigt: Wenn ich eine relationale Datenbank habe, in meinem Programm aber mit Objekten arbeiten will, muss ich dann tatsächlich ein Objekt definieren und beim Einlesen der Daten, diese in ein Objekt kopieren? Soll man also Klassen für Datensätze definieren? Wenn die Fragestellung hier so gemeint ist, ist sie sicherlich interessant.

[fkf]

Zitat:

Aber auch ein anderer Aspekt hat mich damals wie hier in der Fragestellung beschäftigt: Wenn ich eine relationale Datenbank habe, in meinem Programm aber mit Objekten arbeiten will, muss ich dann tatsächlich ein Objekt definieren und beim Einlesen der Daten, diese in ein Objekt kopieren? Soll man also Klassen für Datensätze definieren? Wenn die Fragestellung hier so gemeint ist, ist sie sicherlich interessant.

Genau das ist meine (ungelöste) Frage, die ich bisher (aus Bequemlichkeit/Unkenntnis) immer mit "Nein" beantwortet habe.
Eine vertiefende Diskussion (inkl. prakt. Vorgehensweise/Beispielen) wäre super.

F.F.

[Lemmy]

Zitat von fkf:

Zitat:

Aber auch ein anderer Aspekt hat mich damals wie hier in der Fragestellung beschäftigt: Wenn ich eine relationale Datenbank habe, in meinem Programm aber mit Objekten arbeiten will, muss ich dann tatsächlich ein Objekt definieren und beim Einlesen der Daten, diese in ein Objekt kopieren? Soll man also Klassen für Datensätze definieren? Wenn die Fragestellung hier so gemeint ist, ist sie sicherlich interessant.

Genau das ist meine (ungelöste) Frage, die ich bisher (aus Bequemlichkeit/Unkenntnis) immer mit "Nein" beantwortet habe.
Eine vertiefende Diskussion (inkl. prakt. Vorgehensweise/Beispielen) wäre super.

F.F.

ganz einfache Antwort: Ja - Das hört sich zwar anfänglich recht komplex an (ist es auch) aber der Sinn eines ORM bzw. OPF liegt genau darin dieses Mapping Klasse - Datensatz zu vereinfachen (ganz einfach gesprochen). Wenn das System wirklich gut ist, definierst Du nur eine KLasse, sagst ggf. in welcher Tabelle(n) der Inhalt gespeichert werden soll und der Rest (incl. Anpassung der Datenbank beim Kunden) macht das darunterliegende System. Um einen Datensatz zu laden reicht dann z.B. ein

Delphi-Quellcode:

 var Kunde: TKunde;
begin
  Kunde := TKunde.create(1);
...
end;

wobei 1 die ID des Datensatzes ist. Die Abfrage der Daten in der Datenbank und die Zuordnung zur Klasse geschieht dann in 2-3 Methoden die für alle Klassen funktionieren - die müssen also nicht immer für jede neue Klasse individuell geschrieben werden.


Grüße

[Sir Rufo]

Zitat von fkf:

Zitat:

Aber auch ein anderer Aspekt hat mich damals wie hier in der Fragestellung beschäftigt: Wenn ich eine relationale Datenbank habe, in meinem Programm aber mit Objekten arbeiten will, muss ich dann tatsächlich ein Objekt definieren und beim Einlesen der Daten, diese in ein Objekt kopieren? Soll man also Klassen für Datensätze definieren? Wenn die Fragestellung hier so gemeint ist, ist sie sicherlich interessant.

Genau das ist meine (ungelöste) Frage, die ich bisher (aus Bequemlichkeit/Unkenntnis) immer mit "Nein" beantwortet habe.
Eine vertiefende Diskussion (inkl. prakt. Vorgehensweise/Beispielen) wäre super.

F.F.

Weil man dabei anders denken muss

Erst erstellt man die benötigten Objekte, die für die Problemlösung gebraucht werden
Dann die notwendigen Methoden (Suchen, Laden, etc.)

Dann schafft man sich die Speicherstruktur (z.B. eine Datenbank) die alle diese Anforderungen erfüllen kann

Diese Speicherstruktur kann dann auch nach Belieben geändert werden (Datenbanksystem X, Dateibasiert, Webservice, etc.) solange diese alle Anforderungen erfüllt.

[süden]

Na, da habe ich ja was angestoßen ....

... ich schließe mich meinen Vorrednern an, Ihr habt's alle getroffen, was ich meine.

ORM bzw. OPF ??? Das Rad neu erfinden? Gibts doch schon, welche sind gut?

Ich habe mich schon damit beschäftigt.
In der Fachliteratur wird das alles schön strukturiert und logisch dargestellt.

Aber in Bezug auf Datenbankanwendungen UND Praxis (wenns kein Hobby ist) habe ich nicht viel gefunden.
Datenbank = schon Klassen usw.

Es geht mir darum, es besser und auf Dauer einfacher und sicherer zu machen.
Dabei möchte ich nicht "mit Kanonen auf Spatzen schießen" nur weil es so schön ist, etwas zu können.

Erstmal vielen Dank für das Interesse und die Antworten.
Ich habe erfahren, ICH BIN NICHT ALLEIN, schon mal ein gutes Gefühl.

[MrSpock]

Dann will ich mich auch mal outen, ist ja gerade wieder aktuell

Ich nutze für das Einlesen von Daten aus Datenbanken für die einzelnen daten nicht selbst erzeugte Klassen. Ich nutze FibPlus als Komponenten und lesen dann Daten ein, die in DBGrids oder anders dargestellt werden. Das modifizieren von Daten geht dann ggf. über diese Komponenten oder auch mal über Methoden, die aber dann nicht dem Datenobjekt zugeordnet sind. Was ich damit meine will ich an einem kleinen Beispiel erklären. Angenimmen ich habe ien Bestellung mit Positionen. Dann habe ich all diese Daten in einer Datenbank. Es gibt aber in meinem Programm kein Objekt AktuelleBestellung, die die Daten enthält. Ich erzeuge dann eine Rechnung, auch dazu gibt es keine Methode in der Form AktuelleBestellung.ErzeugeRechnung, weil es ja das Objekt nicht gibt. In diesem Sinne landen die Daten also in der Regel in meinen Programmen nicht in "zugehörigen" Objekten.

[mkinzler]

Zitat:

ORM bzw. OPF ??? Das Rad neu erfinden? Gibts doch schon, welche sind gut?

(Reihenfolge ohne Wertung)
hcOPF
dORM
mORMot
tiOPF
TMS Aurelius

[Jumpy]

Vielleicht nur zuviel reininterpretiert, aber imho geht die ursprüngliche Frage aber auch noch weiter.

Zitat:

Bisher habe ich: Komponenten drauf, paar Zeilen Code - fertig. Nix Klassen usw.

Da geht's find ich nicht nur um OOP vs. Prozedurale Progrmmierung, sondern auch um Trennung der Anwendungslogik von der Darstellung usw. bis in Richtung der ganzen Pattern-Geschichten.

Und vielleicht auch RAD vs. "vernünftiger Struktur"?

Mich interessiert dieser Gedanke nämlich auch, da ich mitlerweile auch versuche Logik und GUI zu trennen, ich aber oft auch nur so kleine Mini-Programme auf die schnelle machen muss, wo irgendwer sich ein paar Daten aus der DB mit anzeigen lassen muss um dann ggf. diese zu Filtern und als CSV zu exportieren und das war's dann schon.
Und da mach ich's dann auch wie der TE. Paar VCL-Komponenten drauf und fertige VCL-Objecte wie TStringlist verwendet und fertig, da der Mehraufwand mit Pattern usw. sich da kaum lohnt.

Sprich irgendwo gibt es wahrscheinlich eine Grenze ab wann es sinnvoll wird "vernünftig" zu arbeiten.