Hallöle...
Deine Gedanken sind richtig. Wie leicht kannst du noch einen Schritt weiter machen...
Zitat:
Würdet Ihr von einer zentralen Stelle mit den
SQL-Queries gleich eine
Query-Komponente zurückgeben
Ja...zentral. Hier bietet sich eine abstrakte Klasse oder Interface je
DBMS an. Die Anwendung kennt kein
DBMS. Sie arbeitet auf Dataset Ebene oder mit Listen. (Beispiel: GetDatabaseVersion)
Delphi-Quellcode:
function TDatabase.CreateQuery: TUniQuery;
begin
Result := TUniQuery.Create(
nil);
Result.Connection := FMeineConnection;
end;
...
procedure TDatabase.GetDatabaseVersion;
var
Query: TUniQuery;
begin
Query := CreateQuery;
try
Query.SQL.Text := '
SELECT F_VERSION FROM T_VERSION';
Query.Open;
FDatabaseVersion :=
Query.FieldByName('
F_VERSION').AsInteger;
finally
Query.Free;
end;
end;
...
procedure TDatabase.FillQuery(
Query: TDataSet);
Query: TUniQuery;
begin
Query := CreateQuery;
Query.SQL.Text := '
SELECT F_BlBB FROM T_BLA';
Query.Open;
end;
Zitat:
oder nur einen
SQL-String für eine Komponente?
Du hast keine Komponenten mehr auf der Form.
Das Statement ist in der Klasse definiert.
Query.SQL.Text := 'SELECT F_VERSION FROM T_VERSION'
Die Funktion gibt das
neuerzeugte TDataSet oder die Liste zurück...enweder als Result oder var Parameter.
Eine andere Möglichkeit ist die Statements extern zu verwalten in Ressourcen. Wenn du es wissen willst kann ich nochmal darauf eingehen.
Zitat:
Nachteil wäre, dass ich (in der
IDE) keine persistenten Felder mehr nutzen kann, an die ich z.B. Standard-AufbereitungsRoutinen (in OnGetText) hängen kann.
Die Aufbereitung von Feldern z.B. für ein TDBGrid müsste dann auch im Grid erfolgen.
Ebenso müsste ich auf Lookup-Felder verzichten
Wenn du die datensensitiven Komponenten wegläßt, hast diese Probleme nicht mehr.
Wenn du dir Datenklassen baust, kannst du auch komplexe Daten an die Nodes oder Zeilen hängen.
Zitat:
Die Aufbereitung von Feldern z.B. für ein TDBGrid müsste dann auch im Grid erfolgen.
Die Berechnerei kannst dann in der Klasse erledigen statt im Visuellen Control. Das macht dich unabhängig...
Zitat:
Wenn man den Parameter-Gedanken weiterspinnt, dann wäre es doch sinnvoll, für jede Abfrage eine eigene Routine zu machen, die ein
Query liefert und konkret benannte und typisierte Werte entgegen nimmt. Andernfalls müsste ich immer die Parameter-Namen bzw. -Positionen nachschlagen
Jawoll..ja.
Wenn man weiterspinnt...
Delphi-Quellcode:
function TDatabase.Save(Blubb: TBlubbClass): Integer;
var
Qry: TUniQuery;
begin
Result := -1;
Qry := CreateQuery;
try
case Blubb.State of
ddsNew:
begin
Qry.SQL.Text := GetSQLByName('SER_INSERT_BLUBB'); // aus Ressource
Qry.ParamByName('UID').AsInteger := Blubb.UserID;
Qry.ParamByName('GRO').AsString := Blubb.Group;
Qry.ParamByName('DEF').AsInteger := 0;
Qry.ExecSQL;
Blubb.ID := Qry.ParamByName('RET_ID').AsInteger; // neue ID direkt im Objekt ... geht bei Firebird
Result := Blubb.ID;
end;
ddsEdit:
begin
Qry.SQL.Text := GetSQLByName('SER_EDIT_BLUBB');
Qry.ParamByName('GRO').AsString := Blubb.Group;
Qry.ParamByName('ID').AsInteger := Blubb.ID;
Qry.ExecSQL;
Blubb.State := ddsNormal;
Result := Blubb.ID;
end;
ddsDeleted:
begin
Qry.SQL.Text := GetSQLByName('SER_DELETE_BLUBB');
Qry.ParamByName('ID').AsInteger := Blubb.ID;
Qry.ExecSQL;
Result := Blubb.ID;
end;
end;
finally
Qry.Free;
end;
end;
...das Objekt kennt seinen Status. Dann speichere mal mein Blubb Objekt mit
DatabaseInstanz.Save(Blubb)
...fertsch.
Weiter so...