Datenbankanwendung und Klassen - sinnvoll?

[MrSpock]

Zitat:

Zitat von DeddyH (Beitrag 1242962)

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

Ich glaube schon. :-D

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:

Zitat von fkf (Beitrag 1242965)

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

[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.

[Sir Rufo]

Zitat:

Zitat von fkf (Beitrag 1242965)

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 :shock:

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

[stahli]

Zitat:

Zitat von süden (Beitrag 1242927)

ich liebäugel schon lange mit Klassen (nicht lachen bitte), und habe ein schlechtes Gewissen, weil ich noch keine selbst gebaut habe.

Du musst Dich nicht schämen, das ist nix schlimmes, aber Du solltest daran arbeiten... :stupid:

Das Thema interessiert mich auch sehr. Im Grunde geht es um einen Themankomplex:

- Trennung Daten+Geschäftslogik von der GUI
- lose und einfache Verbindung der beiden Schichten
- effektive und einfache Definition der Klassen
- effektive und einfache Einbindung von Datenbanken (ORM)

Ich finde es schade, dass das Thema bisher so vernachlässigt wird.
Es gibt zwar verschiedene Lösungen für einzelne Teilaspekte aber m.E. nichts was alles abdeckt.

Im Grunde geht es daraum:
- Ich will sehr einfach Klassen definieren. Bestenfalls über Metadaten (also Auflistung der gewünschten Probpertys) oder sogar grafisch. Die grundlegenden Eigenschaften und Fähigkeiten sollen automatisch vorhanden sein.
- Ich will den Klassen die Geschäftslogik (Methoden) hinzufügen können.
- Ein Framework soll sich darum kümmern, die Objekte zu erzeugen, zu verwalten und auf Anfrage bereit zu stellen (Kunde(12345)).
- Die Datenspeicherung soll ebenfalls automatisch und möglichst flexibel erfolgen.
- Die GUI soll keinerlei Kenntnis der Daten und Geschäftslogik haben. Sie soll lediglich wissen, welche Daten sie darstellen soll (Namen eines Kunden oder Kennzeichen eines KFZ) und wo sie diese abrufen kann. Die GUI sollte also weitgehend ohne Quelltext auskommen. Wenn ein KFZ-Objekt in seiner Eigenschaft HatTÜV false liefert könnte ein OK-Schalter deaktiviert werden, ohne dass die GUI selbst weiß warum.
Dafür muss die Datenschicht natürlich Schnittstellen bereit stellen, an die die GUI gebunden werden kann.


Grundsätzlich würde ich komßplexere Projekte eher mit Klassen aufbauen, da die Projekte dann aus meiner Sicht flexibler zu warten und besser zu verstehen sind.
Andererseits ist es natürlich auch möglich, die gesamte Funktionalität in Datenbanken zu packen und dann in der GUI nur noch dumme DB-Controls zu verbauen.
Letztlich ist das Geschmacksache und von den eigenen Fähigkeiten abhängig (bzw. davon was man als Entwickler besser kann).

Wichtig ist auf jeden Fall, die Geschäftslogik nicht in der GUI umzusetzen und beides miteinander zu vermischen. Dann hat man schon mal die besten Voraussetzungen für eine vernünftige Projektstruktur.

Ich würde mir wünschen, dass Delphi diesbezüglich besser unterstützen würde.



Hier mal einige Links, die in diese Bereiche gehen:
http://www.delphipraxis.net/164573-d...nd-hoeher.html
http://www.delphipraxis.net/161102-k...onisieren.html
http://www.delphipraxis.net/172249-d...iskussion.html
http://www.delphipraxis.net/165090-g...nkprojekt.html
http://www.delphipraxis.net/164270-k...zu-mormot.html
http://www.delphipraxis.net/176478-m...realitaet.html

Und natürlich:
[Werbeblock]
http://www.delphipraxis.net/173360-s...framework.html
[/Werbeblock]

[p80286]

Kann sein, daß ich Dich da falsch verstanden habe:

Zitat:

- Die GUI soll keinerlei Kenntnis der Daten und Geschäftslogik haben. Sie soll lediglich wissen, welche Daten sie darstellen soll (Namen eines Kunden oder Kennzeichen eines KFZ) und wo sie diese abrufen kann.

Wenn das (G)UI keine Ahnung von den Daten hat, dann übergibst Du kein KFZ-Kennzeichen, sondern einen 10(?)stelligen alphanumerischen Code.

Übrigens würde ich zumindestens die "Oberflächenlogik" als Teil des UI behandeln. Typische Schreibfehler erkennen, ist oft von der eingesetzten Tastatur(sprache) abhängig. Damit würde ich die "Geschäftslogik" nicht belasten.

Gruß
K-H