Puh, ok ...
Erstmal vielen Dank für Deine ausführliche Antwort. Die muss ich erstmal verarbeiten. Hier ein erster Versuch einer Erwiderung...
1. Zu Deinem ersten Beispiel: die FillQuery-Methode hat
Query als Var. und Param. Da ist mir die Funktionsweise nicht ganz klar. Soll der Parameter mit einem
Query versorgt werden (falls er bei Übergabe nil ist)? Dann müsste er als var übergeben werden. Wenn er gefüllt ist, müsste man erst einen Close machen, falls er noch aktiv ist:
Code:
if Assigned(
Query) then begin
if
Query.Active then
Query.Close;
end
else
Query := CreateQuery;
2. Wenn ich komplett auf Komponenten verzichte, dann müsste ich ja "einfache" TLabel, TEdit, ... einfügen und mit DataToForm- bzw. FormToData-Methoden die Felder befüllen (KundenNrLabel.Caption :=
Query.FieldByName('KUNDENNR').Text). Das wäre jetzt (solange man auf TDataSet als Basis setzt) datenbankunabhängig. Würden diese Zuweisungen dann in meiner Zugriffsklasse in einer entsprechenden Methode passieren, in der auch der
Query gebildet wird? Dann wäre QueryString und Zugriff auf Felder/Feldnamen beisammen. Auf externe Ressourcen gehe ich mal noch nicht ein, das überfordert mein Hirn gerade. Eins nach dem anderen
Würde man das dann in eine Methode "KundeToForm(const Vorname, Nachname, Strasse, Ort : TControl" packen, der ich diverse Controls übergeben kann (TLabel, TEdit, ...) und die Werte dann zugewiesen werden, wenn ich ein Control übergeben habe (if Vorname is TLabel then ... else if Vorname is TEdit then ...)?
3. TGrid: Würdest Du dann ein CustomGrid machen und die Verbindung zu
Query selbst bauen? Oder ein datensensitives TDBGrid nehmen, das dann alle gelieferten Felder anzeigt, wenn ich es zur Laufzeit mit einem TDataSet verbinde? (Dritt-Komponenten mal außen vor)
4. Dein Beispiel mit den Save-/Load-Methoden: die TBlubbclass würde nun meine fachlichen Daten enthalten. Aber in der Save-Methode von TDatabase wird dann doch "Wissen" der Tabelle benötigt, da Du ja die Felder UID und GRO explizit ansprichst. Oder sollten die grundsätzlich immer bei allen Tabellen da sein? Oder Wird TDatabase für jede Tabelle abgeleitet und Load/Save entsprechend auscodiert?
5. An den Aufruf "GetSQLByName" hatte ich auch schon gedacht. Aber dann muss der Aufrufer ja doch wieder wissen, wie die Parameter und die gelesenen Felder heißen von dem, was GetSQLByName liefert. Da finde ich es praktischer, hier gleich den
SQL-String stehen zu haben, dann sehe ich beim auscodieren der FieldByName-Aufrufe gleich wie meine Felder heißen. Verstehst Du, was ich meine?
6. Noch ein anderer Gedanke zum "individuellen QueryBuilder": wenn ich z.B. die Daten eines Kunden auf dem Dialog im Kunden-Stamm, auf dem Lieferschein und auf der Rechnung anzeigen will, mache ich dann unterschiedliche Queries zw.
Query-Methoden, da ich beim KundenStam mehr Daten lesen will als für den Lieferschein/die Rechnung? Oder versuche ich die anzahl der verschiedenen Queries klein zu halten und baue nur ein
Query, der immer alle Felder liest und ich verwende dann nur die, die ich im Kontakt gerade brauche?
Viele Grüße
Sneak-L8