DB-Controls oder OR-Mapping

[Hannes Kuhn]

Hallo,

Ich habe mit einer größeren DB-Anwendung begonnen.

Die Datenbank ist erstmal SQLite. Soll dann aber später auf eine Server-DB umgestellt werden (welche ? ist noch offen).

Begonnen hab ich so:
Hol mir die Daten aus der DB mittels SQL, dann erzeuge ich spezielle Objekte und pack dort die Daten rein.
Dann stelle ich die Daten z.B. in einem Grid dar.
Die Daten kann ich dann aus dem Grid in die Objekte schreiben und dann die DB updaten.
Das ist alles sehr flexibel und auch nicht die große Arbeit.

Was ist Eure Meinung ?
Diesen Weg fortführen oder doch lieber DB-Controls verwenden.
Bitte auch ein paar Gründe zu Eurer Meinung.

Vielen Dank
Hannes

[Bummi]

Sieht für mich ein bisschen aus wie zwei mal um die Ecke.
Ich bevorzuge KISS.

[mkinzler]

http://blog.synopse.info/category/Op...ite3-Framework

[Hannes Kuhn]

Hallo,

schon mal danke für Eure Antworten.

Ich bin ja genau auf der Suche nach der „möglichst einfache, minimalistische und leicht verständliche Lösung meines Problems“.

Bummi, wie kann ich die Anzahl der Ecken reduzieren ?

Bringt mir ein „SQLite3 Framework“ wirklich so viele Vorteile und nicht doch irgendwann Kopfweh ?

Viele Grüße
Hannes

[shmia]

Es kommt drauf an.
Beispiel: es gibt eine Tabelle Artikelstamm.
Dieser Artikelstamm soll vom Benutzer gepflegt werden können.
Ausserdem werden die Artikel irgendwo im Programm benützt;
es gibt Artikellisten, Artikel mit der gleichen Nummer werden aufsummiert..., Preis * Stückzahl = Gesamtpreis

Zum Pflegen des Artikelstamms würde ich einfach eine Query, Datasource und DBGrid verwenden
und fertig ist die Laube.
Würde man hier mit Stringgrids und Objekten arbeiten, würde man die 10-fache Zeit benötigen
und hätte immer noch nicht den Komfort eines DBGrids.

Wenn man später mit den Artikeln arbeitet sieht die Sache anderst aus.
Jetzt kommt Logik mit ins Spiel - Artikel mit gleicher Artikelnr werden aussummiert usw.
Hier braucht man mindestens die Klassen TArtikel und TArtikelList.

[Hansa]

Du hast Dich aber da wirklich sehr missverständlich ausgedrückt. 8-)

Es geht dabei um Satzzeichen und Schreibfehler. Ist schon klar, das ist alles unwichtig. :P Ich werde den Beitrag deshalb etwas zerpflücken. :mrgreen:

Zitat:

Zitat von shmia (Beitrag 1059709)

es gibt Artikellisten, Artikel mit der gleichen Nummer werden aufsummiert..., Preis * Stückzahl = Gesamtpreis

Bei Artikellisten werden normalerweise keine Artikel mit gleicher Nr. "aufsummiert". Wäre das "," ein "." (in dem Satz), dann wirds so ungefähr hinhauen. 8-) Aber nur fast. Bsp.: was, wenn Stückzahl = 10 bestellt wird und es sind nur 8 am Lager ? Jetzt wird derselbe Artikel nachgeliefert (2 Stück). Der Besteller hat dann die 10. Er schickt aber 3 Stück wieder zurück, weil er sich vertan hat. So ich habe jetzt 3 Fälle : Erstlieferung, die Nachsendung und die Rückgabe. Summiere ich das auf, dann kriegt er Rechnung über 7 Stück (bei identischen Art.Nummern).

Und nun ? Ich will jetzt nicht zu spitzfindig werden, aber so etwas stiftet eventuell nur Verwirrung. Der Besteller wird wohl mehr Ärger machen, als das Ganze wert ist.

Zitat:

Zitat von shmia (Beitrag 1059709)

Artikel mit gleicher Artikelnr werden aussummiert usw.

"aussummiert" ? :shock: Soll wohl "aufsummiert" heissen. Kommentar dazu : siehe oben. Aber das ist relativ egal.

[Lemmy]

Hallo,

nach meiner Erfahrung bringt ein OR-Mapping dann was, wenn Du umfangreiche Business-Regeln umsetzen musst. Das geht innerhalb eines Klassenmodells in der Regel einfacher als über StoredProcedures. WEnn es allerdings nur darum geht, eine Adresse, eine Rechnung und div. Artikel miteinander zu verbinden, ist die "normale" DB Anbindung einfacher zu realisieren (Ausnahme: Du bist im Einsatz eines bestehenden OPF so fit, dass du das da schneller hinbekommst)

Bevor du aber was eigenes anfängst, solltest Du dir die bestehenden mal anschauen (InstantObjects, tiOPF). Weiterhin solltest Du dir vor der Implementierung div. Szenarien auf dem Papier durchspielen, d.h. welche Anbindung an die Oberfläche (MGM-Pattern), welche Daten werden von der DB geholt ("Select *" und alle Objekte gleich anlegen oder gibts Proxies,....). Und falls Dir das fehlt: die theoretischen Hintergründe eines OPF. Ich habe hier 2 Dokumente die den (groben) Aufbau eines OPF beschreiben (http://www.ambysoft.com/downloads/persistenceLayer.pdf und http://www.tabdee.ltd.uk/papers/BuildingAnOpf.html).

Ein OPF hört sich immer interessant an, aber wenn man hier Designfehler hat, bereut man den Einsatz zumindest so lange man die Software pflegen muss. Je nach Umfang sollte auch ein Unit-Test möglich sein, was aber auch wieder gewissen Anforderung an das Klassendesign voraussetzt...

Grüße

[mjustin]

Eine Liste von ORM für Delphi Win32 ist hier zu finden:

http://stackoverflow.com/questions/4...r-delphi-win32

Wenn es um größere Anwendungen geht, würde ich definitiv auch einen Blick auf die verfügbaren ORM und ihre Unterschiede werfen. Wenn sie leicht in Oberflächen eingebunden werden können, z.B. durch die Verwendung von Datasource / DBEdit, kann das den Einstieg sehr vereinfachen. Auch für Serveranwendungen können ORMs sehr vorteilhaft sein, wenn z.B. aus Performancegründen anstatt einzelner Datenbankabfragen ein Caching von Objekten erforderlich wird.

Leider ist Bold nicht mehr erhältlich, das eines der besten ORM für Delphi gewesen sein soll. Mit den neuen Sprachfeatures seit Delphi 2010 (Attribute und erweiterte RTTI) haben neu entwickelte ORMs allerdings technologischen Vorsprung, wenn man wie z.B. bei (N)Hibernate und Co. mit wenig Attributen zu den Properties das Mapping parametrisieren kann.