Ablage der SQL-Statements

[Andreas H.]

Ach sch....

ich glaub, ich speichere die SQLs doch in den Komponenten. Ist doch übersichtlicher...

[mkinzler]

Zitat:

ich glaub, ich speichere die SQLs doch in den Komponenten. Ist doch übersichtlicher...

Kann ich mir nicht vorstellen.
Eine weitee Alternative wäre die Verwendung von mehreren Datenmodulen.

[Bernhard Geyer]

Oder die Verwendung einer abstrakteren DB-Schnittstelle (Bridge-Pattern läßt grüßen). Z.b. Methoden der Art GetAllCustomer, GetCustomerById, ... und erst in der für jeder DB vorhandenen Implementierungsunit wird die passende SQL-Anweisung zusammengebaut. Damit würde man einen DB-Unabhängiger Ansatz ähnlich (N)Hypernate/ECO realisieren.

[mkinzler]

Man könnte den DB-spezifischen Code auch durch ORM kapseln.

[Sir Rufo]

Hallo Andreas,

habe gerade mal kurz in deinen Quellcode geschaut ...

was mir sofort auffiel, war das die GUI-Elemente und die DB-Elemente bei dir in einem Topf liegen (DocsChild.pas).
Nicht nur dass dies völlig gegen ein sauberes Programmierkonzept läuft (Ein-/Ausgabe von der Verarbeitung trennen), sondern es wird dich gerade dann die "Torte im Auge treffen" wenn du unterschiedliche Datenbanken ansteuern möchtest.

Trennst du diese Teile auf, so kannst du die entsprechenden (Verarbeitungs-)Units an die jeweilige Datenbank anpassen und bei Bedarf mitkompiliern und so unterschiedliche Versionen von deinem Programm erstellen (MySQL-, Oracle-, etc. Version).

Denkbar wäre ja auch die Kapselung in einer DLL und diese dann beim Programmstart dynamisch einbinden (welche DB hätten Sie denn gerne).

Zudem kann bei so einer Trennung auch die Programmierung sehr schön auf mehrere Personen verteilt werden (GUI, DB1, DB2 ... )

cu

Oliver

(PS: Ich weiss das so gut, weil ich noch einige Alt-Projekte hier rumliegen habe, wo ich das nicht beachtet hatte und jetzt muss ich diese anpassen - )