Mehrere Projekte aber gemeinsame DataModule

[Sigi55]

Hallo Zusammen,

ich steh vor einem Designproblem:

Ich habe mehrere Projekte einzeln entwickelt und möchte die jetzt zu einer Projektgruppe zusammenfassen,
da sie eigentlich alle die gleichen oder ähnliche units verwenden.

Also:

1.Ordner Projekt1
2.Ordner Projekt2
usw...
Ordner GemeinsameUnits(da liegen dann die gem. genutzten units drin)

Geht auch alles soweit gut.

Jetzt möchte ich aber auch die DataModule gemeinsam nutzen...
1. DataModule Paradox.DB (.. ich weiss, Steinzeit:(, geht aber nicht anders)
2. DataModule MS Sql
3. DataModule MySql

Das Problem ist, das die Events wie ...OnGetText, ...OnDataChange, etc.
natürlich in den unterschiedlichen Projekten anders ausgewertet werden
müssen.

Wie kann ich das auseinanderhalten?

Kann ich das über den ExeNamen regeln?

Kann ich die Events/Proceduren vom DataModule auf die Hauptform
verlagern ?

Wie geh ich das an oder geht das garnicht ?

Ich steh da auf'm Schlauch, hat jemand ne Idee?
Danke.

Gruß

Sigi

[Der schöne Günther]

Ich finde, anwendungsabhängig ist nur der TDataSource. Datenmodule für DB-Zugriff oder sonstwas habe ich immer allgemein gehalten und verwende die immer gerne in ganz anderen Projekten wieder. Der DataSource der auf ein TdataSet zeigt habe ich nie direkt auf den geshareten Datenmodulen sondern irgendwo anders untergebracht. Gerne auch direkt auf dem GUI-Formular wenn es denn für einen DBGrid oder LiveBindings dort ist.

Kann aber auch sein, dass ich die Frage falsch verstanden habe. Oder die grundlegende Philosophie hinter Datenkomponenten. Oder beides.

[Sigi55]

Zitat:

Zitat von Der schöne Günther (Beitrag 1259570)

Kann aber auch sein, dass ich die Frage falsch verstanden habe. Oder die grundlegende Philosophie hinter Datenkomponenten. Oder beides.

Hallo Günther,

DAS ISSES !! Du hast alles richtig verstanden :-D
Als ich mit Delphi angefangen habe, so vor ca. 3 Jahren,
hab ich mir alle Komponenten auf die Form gepackt bis ich nix
mehr sehen konnte:lol:
... und dann bin ich irgendwann über das DataModule gestolpert
und hab dann richtig "sauber gemacht", alles was irgendwie mit Datenbanken,
etc. zu tun hat, ab in das DataModule.
Ich brauch ja nur die DataSources wieder auf die entsprechende Form packen
und alles ist wieder hübsch.
Super, Danke für den Anstoß!

Gruß

Sigi

PS.: Ich merke, ich hab noch viele grundsätzliche Lücken in Delphi, die
letzte Sprache in der ich etwas geschrieben habe war Clipper mit dBase.dbf's
und das ist 20 Jahre her ...

[Perlsau]

Zitat:

Zitat von Sigi55 (Beitrag 1259566)

Wie kann ich das auseinanderhalten?

Du könntest deiner Datenmodul-Klasse ein Property verpassen, das von der jeweiligen Haupt-Unit gesetzt wird. Anhand der unterschiedlichen Werte, die dieses Property zugewiesen bekommt, unterscheidest du, welche der Anwendungen gerade gestartet wurde.

Zitat:

Zitat von Sigi55 (Beitrag 1259566)

Kann ich das über den ExeNamen regeln?

Erscheint mir unzuverlässig, denn schließlich kann der Anwender den Exenamen leicht ändern.

Zitat:

Zitat von Sigi55 (Beitrag 1259566)

Kann ich die Events/Proceduren vom DataModule auf die Hauptform verlagern?

Natürlich kannst du das, erscheint mir aber nicht wirklich sinnvoll, zumal die Hauptform bei größeren Anwendungen sowieso schon recht vollgestopft ist.

Zitat:

Zitat von Sigi55 (Beitrag 1259566)

Wie geh ich das an oder geht das garnicht?

Wie gesagt: Anhand des Property-Wertes – das Property könntest du z.B. ApplicModus nennen – verzweigst du dann in die jeweils benötigten Proceduren, z.b. zum Aktivieren der Connection-Componente, der Queries oder Datasets und schließlich der Zuweisung dieser Datasets an die jeweiligen Datasources.

[jaenicke]

Die Richtung sollte im Gegenteil umgekehrt sein:
Statt diese Events in das Hauptformular zu verlagern solltest du besser ein weiteres (anwendungsspezifisches) Datenmodul dazwischenschalten, das dann nicht nur diese bekommen kann, sondern das auch gleich Funktionalität des Hauptformulars ausgelagert bekommen kann.

So erwischst du zwei Fliegen mit einer Klappe, deine anwendungsspezifische Datenanbindung und eine Verschlankung des Hauptformulars. Das erleichtert das ganze sehr, wenn du z.B. einmal eine neue GUI entwickelst oder die Anwendung als Dienst laufen lassen möchtest, da in der GUI selbst schon weniger drin steckt.

Eine andere Möglichkeit sind projektspezifische Compilerdirektiven (gesetzt in den Projektoptionen), die du per IFDEF abfragen kannst. Dafür müssen deine Anwendungen aber verschiedene Ausgabepfade für die DCUs haben.

[dataspider]

Ich habe auch Datenmodule für mehrere Projekte.
Aber diese enthalten nur das, was in allen Projekten gleich ist.
Ich binde diese auch ein in jedes Projekt, leite diese aber dann noch ab.
Das ist mir so lieber, sonst ändere ich ja jedes Mal, wenn ich ein Datenmodul anfasse, alle Projekte.

Frank

[Sigi55]

Hallo Zusammen,

erstmal Danke für's "Auf die Sprünge helfen :-D".

Das wird wohl ne Mischung aus beiden Vorschlägen werden,
wenn ich mir das so richtig vorstelle:

1. gemeinsame DataModule für die Datenverbindungen, Queries und Tabellen
2. anwendungsspez. DataModule für die Datasources, Eventhandling für OnChange, etc.
3. Property für die Hauptform, sodaß ich in dem gem. DataModule, unterschiedliches
Eventhandling für z.b. OnCalcFields, etc. auseinanderhalten kann.

Lieg ich da so richtig?

Auf der anderen seite, wenn ich sowieso ne Property setze, kann ich sie auch
für die Datasources nutzen oder ?

Noch Vorschläge, (Hauser)?