Welche schreibweise ist besser , mit oder ohne Variablen

[nailor]

Zitat:

Zitat von negaH

Besser ist es die Feld Komponenten zur Laufzeit zur Table anzulegen. Die bringt mehr Performance, ist stimmiger zum OOP Konzept, Tpysicherer und für Anfäger besser zu verstehen. Der Source sähe dann so aus:[...]

*möööp*

[rocksoft]

Vielen Dank für die ganzen antworten, aus den 2 möglichkeiten sind es jetzt 5 geworden.

- a)
- b)
- c) mit konstanten
- d) MachDies(Table1Text1.AsString, Table1Text2.AsString, Table1Text2.AsString);
- e) *möööp*

meine meinung die beste (für mich) ist die variante c), b) und d) ist gleich nur die schreibweise ein wenig anderes, und bei e) die muss echt gut sein nur leider bekomme ich nur errors :)

also Danke für die Hilfe

[StefanDP]

Von deinem ersten post kannst du ja auch schreiben: (reine optik sache)

Delphi-Quellcode:

procedure Tform.BtnOkClick(Sender: TObject); 
begin 
functionmachdies(table1.FieldValues['Text1'],
                 table1.FieldValues['Text2'],
                 table1.FieldValues['Text2']) 
end;

und schon ist es so übersichtlich wie b) von deinem ersten post

[rocksoft]

Hallo StefanDP,

mensch was ein paar Tabs ausmachen:), ja so ist es wirklich schön zu lesen.

Danke

[negaH]

Zitat:

b) und d) ist gleich nur die schreibweise ein wenig anderes

Nein eben nicht. Alle Methoden sind gleich bis auf d.)
Während alle Methoden langsam, dynamisch und fehlerträchtig sind ist die methode d.) über zur Designzeit angelegte Field-Komponenten übersichtlich, wesentlich schneller, typsicher und universeller.

Angenommen wir möchten ein DBGrid nutzen und ein Fließkomma Datenbankfeld extra formatieren und eine extra Konvertierung der Eingaben durchführen. Man legt dann zum DateSet alle Feldkomponenten an. Innerhalb dieser Feldkomponenten besteht nun die Möglichkeit über .DisplayFormat den Inhalt den Datenbankfeldes im DBGrid zu formatieren. Nun möchte man noch zusätzliche Konvertierungen berücksichtgen was ganz einfach über die Ereignisse der Fieldkomponente möglich ist. Dies geht ALLES nicht wenn man wie oben dynamisch auf die Felder einer DB zugreift, bzw. es ist sinnlos dynamisch auf die Felder zuzugreifen wenn man schon Field Komponenten angelegt hat.
Zb. eine Tabelle enthält 50 Datenbankfelder. Wenn man wie oben dynamisch darauf zugreift so muß die DB-VCL per Stringvergleiche im Durchschnitt 25 Strings vergleichen -> nämlich die Feldnamen des gesuchten Feldes mit den Feldnamen in der DB. Im obigen Falle wären also ca. 75 Stringsvergleiche bei 50 Datenfeldern nötig. Legt man aber zur Designzeit Feldkomponenten an und greift über .AsString zur Laufzeit auf deren Inhalte zu so stellt dies ein DIREKT Zugriff dar, also ohne Feldnamen's -Vergleichen.

Somit unterscheidet sich mein Vorschlag von allen anderen gravierend. Er ist NICHT die beste Lösung für dein Problem mit einer besseren Source-Formatierung, sondern er stellt DIE beste Lösung im gesammten dar, wenn man mit DataSets + Fields arbeiten will.


Gruß Hagen

[choose]

Ich stimme Hagen zu, sofern der Code wiederholt und die Entwicklung durch die IDE (zum durch den Formulardesigner) unterstützt wird. Sollten die Referenzen selbstständig angelegt werden müssen (zB weil die Feldbezeichnungen erst zur Laufzeit bekannt sind) und sollte der Code nur einmal ausgeführt werden, ist der zusätzliche Aufwand für die Verarbeitung wohl ungerechtfertigt.

Für diesen Fall schlage ich eine Variante der von StefanDP gezeigten Lösung vor

Delphi-Quellcode:

procedure Tform.BtnOkClick(Sender: TObject);
begin
  with Table1 do
    FunctionMachDies(FieldValues[Field0], FieldValues[Field1], FieldValues[Field2]);
end;

wobei Field0, Field1, Field2 Variablen oder Konstanten sind.