DB-Controls oder OR-Mapping

[Hansa]

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

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

Zitat von shmia:

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. 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 von shmia:

Artikel mit gleicher Artikelnr werden aussummiert usw.

"aussummiert" ? 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.