![]() |
Datenbank: SQLite • Version: 3 • Zugriff über: direkt
DB-Controls oder OR-Mapping
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 |
AW: DB-Controls oder OR-Mapping
Sieht für mich ein bisschen aus wie zwei mal um die Ecke.
Ich bevorzuge KISS. |
AW: DB-Controls oder OR-Mapping
|
AW: DB-Controls oder OR-Mapping
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 |
AW: DB-Controls oder OR-Mapping
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. |
AW: DB-Controls oder OR-Mapping
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:
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:
|
AW: DB-Controls oder OR-Mapping
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 ( ![]() ![]() 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 |
AW: DB-Controls oder OR-Mapping
Eine Liste von ORM für Delphi Win32 ist hier zu finden:
![]() 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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:39 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz