Stil-Frage zu TDataset und co

[Marco Steinebach]

Hallo zusammen,
Da ich gerade an meinem ersten Projekt sitze, das vom guten alten Datei-Zugriff auf DB-Zugriffe umgestellt wird, hab ich mal ein paar Fragen zum guten Stil.

1. Zugriff auf Datenbank-Felder.

Es gibt ja, soweit ich weiß, 3 Möglichkeiten:
a)

Code:

edit1.text := q.fieldByName ('Nachname').asString;

Finde ich nicht so wirklich schön, alleine schon wegen des Risikos der falschen Schreibweisen der Feldnamen.

b)

Code:

const
  fnNachname = 'Nachname';
 ...
  edit1.text := q.fieldByName (fnNachname).asString;

oder
c)

Code:

const
  fnNachname = 3;
   ...
  edit1.text := q.fields[fnNachname].asString;

Eher b) oder c) - oder noch anders?

2. .asXXX
Die typumwandler asString, asInteger, ..., kann man ja nutzen, aber man muss nicht.
Ist es besser, die IMMER zu nehmen, oder wie seht ihr das?

3. Typen, die es in SQL nicht gibt.
Beispiel:

Code:

TFahrzeugtyp = (fPKW, fLKW, fMotorrad);
...
if TFahrzeugTyp (q.fieldByName ('Typ').asInteger) = fMotorrad then

Geht das irgendwie eleganter?

Herzliche Grüße
Wandogau

[Uwe Raabe]

Zu 1) Jedes TDataSet hat im Kontextmenü einen Feldeditor mit dem man die Felder statisch erstellen kann. Dann hat man jeweils eine Komponente zum Feld, die man verwenden kann.

Zu 2) Wenn man die Antwort zu 1) umsetzt, kann man für jedes Feld das property Value nehmen, das dann vom entsprechenden Typ ist.

Zu 3) Einen Record-Helper zu der Enumeration, die den entsprechenden Feldeintrag setzt oder liest. Das kann ein Integer oder der String des Enumeration-Werts sein.

[Jasocul]

Zitat von Uwe Raabe:

Zu 1) Jedes TDataSet hat im Kontextmenü einen Feldeditor mit dem man die Felder statisch erstellen kann. Dann hat man jeweils eine Komponente zum Feld, die man verwenden kann.

Mit allen Konsequenzen, die persistente Felder nach sich ziehen. Ich mache das schon ewig nicht mehr. Wenn man dann noch TDBGrid o.ä. verwendet und dort ebenfalls den Feld-Editor verwendet, kann es schwierig werden. In welchem Feld-Editor muss man die Korrekturen vornehmen, wenn etwas nicht so funktioniert, wie man es erwartet? Bei Programmierung im Team, kann es dann schon eine ziemliche Sucherei werden. Mal abgesehen davon, dass die Suchfunktion im Editor die Sachen im Feld-Editor nicht finden kann.
Bei uns im Team sind persistente Felder jedenfalls ein NoGo.

Zitat von Uwe Raabe:

Zu 2) Wenn man die Antwort zu 1) umsetzt, kann man für jedes Feld das property Value nehmen, das dann vom entsprechenden Typ ist.

Da man bei einer Zuweisung dennoch wissen muss, welcher Typ dahinter steht, halte ich das nicht wirklich für einen Vorteil. Dann sehe ich im Source lieber gleich, welcher Typ das ist, wenn ich As... verwende.

Wenn ich mit vielen Feldnamen im Source arbeiten muss, gibt es eine spezielle Unit, die alle notwendigen Feldnamen als Konstanten enthält. Vertippen gibt es dann nicht mehr.

[Uwe Raabe]

Die neueren Delphi-Versionen zusammen mit FireDAC machen das aber schon deutlich einfacher. Längen von String-Feldern werden angepasst, andere (z.B. neue) Felder lassen sich zu den statischen dazu nehmen. Man muss diese Möglichkeiten halt nur nutzen.

[TurboMagic]

Wenn die Version des OP noch stimmt ist er noch auf D5!