Hallo zusammen,

ich habe ein Verständnisproblem...

In meinem Projekt nutze ich selbst entwickelte DB-Komponenten. Über ein DataModule wird die Verbindung zur Datenbank (FB über IBX) hergestellt. Meine Komponenten verwenden dann ganz normal diese Verbindungen.

Die Komponenten werden zur Entwicklungszeit oder auch dynamisch zur Laufzeit erzeugt und zeigen Inhalte verschiedener Tabellen an (dabei sind durch einige Komponenteneigenschaften jeweils unterschiedliche Filter- und Sortiereinstellungen, also unterschiedliche Sichten auf die eigentlichen Tabellen möglich).

Nun möchte ich möglichst meinen Komponenten schon in ihren Units bestimmte Datenbankverbindungen zuweisen. Es sollen also möglichst sofort nach dem Erzeugen der Komponenten in der IDE oder zur Laufzeit die entsprechenden Tabelleninhalte angezeigt werden...

MyDBKompo = eigentliche DBKomponente
MyDBKompoKunde = zeigt automatisch Kundendaten an und hat spezifische Eigenschaften
MyDBKompoProdukt = zeigt automatisch Produktdaten an und hat spezifische Eigenschaften

MyDBKompoKunde1 zeigt dann z.B. alle weiblichen Kunden alphabetisch aufsteigend und
MyDBKompoKunde2 alle männlichen Kunden alphabetisch absteigend an. Die Verbindung zu Tabelle TKunden muss aber immer gleich sein. Daher würde eine feste Verknüpfung Sinn machen.

Das Problem:
Beim Erzeugen und Laden der Komponenten existieren das DataModule und die DataSets evtl. noch nicht bzw. kann ich diese nicht eindeutig zuordnen...

Hat jemand solche "fest eingestellten" DB-Komponenten schon einmal genutzt? Wie lässt sich das am besten realisieren?
Oder ist es doch weniger aufwändig, den Komponenten nach dem Erzeugen im OI bzw. zur Laufzeit immer nachträglich das entsprechende DataSet zuzuweisen? Die Feldnamen etc. lassen sich dann ja trotzdem schon fest in der Unit voreinstellen.

Die Eigenschaften zur Filterung und Sortierung müssen natürlich so oder so immer individuell eingestellt werden.

Danke
Stahli

Ich glaube, du bist mit deinen Komponenten etwas auf den Holzweg geraten.
Die Objekte MyDBKompoKunde und MyDBKompoProdukt sind das was man als Bussiness-Objekte bezeichnet.
Die Properties dieser Objekte werden zwar aus der Datenbank geladen und Änderungen werden auch gespeichert; es wäre aber völlig falsch, diese Objekte von einer Datenbank-Komponente abzuleiten.
Vielmehr ist es so, dass die Bussiness-Objekte direkt oder indirekt mit einem Datenmodul kommunizieren und sich so aus der DB laden und speichern können.

Komponenten sind ebenfalls die falsche Technik.
Komponenten sind dafür entwickelt worden, um wie universelle Legosteine in die verschiedensten
Anwendungen eingebaut zu werden.
Deine "Komponenten" sind aber so speziell, dass sie nur in deiner Anwendung verwendet werden können.

Das ganze Thema Laden & Speichern aus/in Datenbank wird meist über ein Persistent Framework abegedeckt. Dabei gibt es aber grosse Unterschiede in der Implementierung und auch die Forschung ist noch nicht abgeschlossen.
Leider kann man diese persistent Frameworks meist nur käuflich erwerben (z.B. Bold oder ECO2).
Open Source gibt es kaum in diesem Bereich (http://sourceforge.net/projects/obiwan ist nie über den Alpha Status gekommen)

Zitat:

Open Source gibt es kaum in diesem Bereich

Es gibt aber noch
-http://www.instantobjects.org/
-http://tiopf.sourceforge.net/

Danke für die Antworten.

Zitat:

Ich glaube, du bist mit deinen Komponenten etwas auf den Holzweg geraten.
Die Objekte MyDBKompoKunde und MyDBKompoProdukt sind das was man als Bussiness-Objekte bezeichnet.
Die Properties dieser Objekte werden zwar aus der Datenbank geladen und Änderungen werden auch gespeichert; es wäre aber völlig falsch, diese Objekte von einer Datenbank-Komponente abzuleiten.
Vielmehr ist es so, dass die Bussiness-Objekte direkt oder indirekt mit einem Datenmodul kommunizieren und sich so aus der DB laden und speichern können.

Na ja, ist auch nicht ganz so...
Meine Kompos sind von visuellen Komponenten abgeleitet (z.B. von TPanel) und beinhalten eine eigene Datenbankkomponete, die sich um den Datenaustausch kümmert.
Unter http://www.delphipraxis.net/internal...ighlight=dbsql ist das mal angerissen.

Zitat:

Komponenten sind ebenfalls die falsche Technik.
Komponenten sind dafür entwickelt worden, um wie universelle Legosteine in die verschiedensten
Anwendungen eingebaut zu werden.
Deine "Komponenten" sind aber so speziell, dass sie nur in deiner Anwendung verwendet werden können.

Die beispielhafte MyDBKompo ist eine allgemein einsetzbare Komponente.
MyDBKompoKunde und MyDBKompoProdukt sind wiederum davon abgeleitet, um individuelle Besonderheiten zu behandeln. So kann die Kundenkomponente z.B. das Kundenalter anzeigen und die Produktkomponente die Produktfarbe darstellen (natürlich nur beispielhaft Jede dieser Komponenten kann vielfach im Projekt instanziert werden... Was steht dem entgegen, dafür eine eigene Komponente abzuleiten?

Mit Bussiness-Objekten und Persistent Framework habe ich mich noch nicht beschäftigt. Ist alles erst mal etwas "unübersichtlich".

Ich werde die DataSets einfach wie bisher nach dem Erzeugen der Komponenten zuordnen. Dann funktioniert ja alles.
Die andere Variante wäre nur hübscher gewesen...

Gruß
Stahli

Ich habe doch noch ein bischen probiert:

In der Methode Paint teste ich jetzt, ob meiner DB-Komponmente noch keine DataSource zugewiesen wurde und das DataModule bereits existiert. In dem Fall weise ich der DB-Komponente die passende DataSource zu...

zusammenfalten · markieren

Delphi-Quellcode:

constructor DBKompo.Create;
begin
  inherited;
  FieldName:='Name';
  ...
end;

procedure Paint;
begin
  if ((DataSource=nil) and (MyDataModule<>nil)) then begin
    DataSource:=MyDataModule.MyDataSource;
  end;
  inherited;
end;

Sobald die Komponente gezeichnet wird und das DataModle (inzwischen) existiert, wird also die DB-Verbindung eingerichtet.

Zur Laufzeit funktioniert das wunderbar. Ich brauche einfach nur die DB-Komponenten erzeugen, einige Einstellungen vornehmen und um die DB-Verbindung kümmern sie sich dann "ganz selbständig".

Während der Entwicklungszeit ist jedoch das MyDataModule nicht instanziert. Ich habe versucht, über GetParentForm oder GetRealParentForm und FindComponent('MyDataModule') weiterzukommen, was jedoch nicht funktioniert hat...

Es wäre einfach sehr schön, wenn ich schon zur Entwurfszeit durch das Einsetzen einer DB-Komponente in das Formular alles komplett hätte. Ich möchte die Komponenten möglichst so aufbauen, dass weder der Nutzer noch der Entwickler merken (obwohl ich es als Entwickler ja eigentlich weiß ), dass da irgendeine Datenbank dahinter steckt.

Weiß jemand, wie ich zur Entwurfzeit an die MyDataModule-Instanz aus der IDE herankomme?
Wie geht denn Delphi mit dem Erzeugen der Formulare und DataModule um? Es muss ja sicher verhindert werden, dass DB-Komponenten erzeugt werden bevor die DataModule erzeugt werden, da sonst keine Verbindung mehr hergestellt werden kann. Oder Delphi merkt sich in einer Liste alle Komponenten, deren DB-Verbindung wegen eines fehlenden DataModuls gescheitert ist und versucht, die Verbindung später nachzuholen.

So etwas könnte ich mir auch ganz gut als Lösung für "feste DB-Verbingen" vorstellen:
- in der Methode Loaded die Existenz des entsprechenden DataModuls testen und dieses dann zuordnen
- wenn dies scheitert, die Komponente in eine TList aufnehmen und einen Timer starten
- solange der Timer läuft, versuchen, die Verbingungen nachzuholen
- bei Erfolg den Eintrag aus der Liste löschen
- wenn die Liste leer ist, Timer beenden

Man müsste eben nur auch zur Entwicklungszeit die MyDataModule-Instanz finden...

Stahli

PS: Feste DB-Verbindungen sollten gar kein Problem darstellen, wenn die Data-Sourcen direkt im Formular plaziert werden. Aber das ist ja keine wirkliche Alternative.