Konstante in Klasse?

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1360946)

...das ist das was du mit einer Ressource erreichen kannst. Mit dem Editor kannst du die Texte deiner Ressource einfach anpassen ohne das der Qelltext verändert wird. Es macht die Klasse schlanker... :thumb:

und Du bist flexibler! Ja ist alles ok, aber in diesem Falle dient die Klasse nur als Hülle für einen sehr speziellen Zweck und ist monolitisch. Da ist nichts mit Vererbung o.ä. Eigentlich ist das Anzeigen des SQL-Textes auch überflüssig und somit könnte der Text irgendwo in der Unit verschwinden, aber angeblich braucht ein Benutzer die Anzeige, und da hätte ich gerne etwas "selbstdokumentiertes". Und falls jemand in absehbarer Zukunft die Klasse überarbeiten muß, wäre sicher gestellt, daß die vorhandenen Definitionen genau zu dieser Klasse gehören.

Gruß
K-H

[haentschman]

Hallo...:P
Da du etwas Spezielles machen mußt...ist das in Ordnung. :P

Zitat:

aber angeblich braucht ein Benutzer die Anzeige

...hier komme ich nicht klar. :gruebel: Man kann auch den SQL Text anzeigen? :gruebel:

Nachtrag:

Delphi-Quellcode:

const
  MaxText = 5;

type
  tSQLTexte = array[0..MaxText] of string;
const
  sqltexte : tSQLTexte = (
    'select * from Tabelle',
    'insert into tabelle where id = :id',
    'delete from tabelle where id = :id',
    'select * from tabelle where id = :id',
    '...',
    '...');

...da du von einer Unit sprachst, würde imho das Beispiel von nahpets dem sehr nahe kommen. Das wäre halt nicht innerhalb einer Klasse... :wink:

[nahpets]

'ne andere Idee:

Warum die SQLs als Konstanten ... vorhalten?

Einfach eine Tabelle in der Datenbank anlegen, die die SQL-Statements enthält. Jedes Statement bekommt 'ne ID, 'ne Beschreibung und natürlich das eigentliche SQL.

SQL-Code:

create table SQLStatements(
id Integer,
Beschreibung VarChar(200),
Statement VarChar(4096)  /* oder Memo oder Textblob je nach Datenbank */
);

create unique index ID on SQLStatements (ID);

Delphi-Quellcode:

function dm.GetSQL(ID : Integer) : String;
begin
  // Das einzige festverdrahtete Statement im Programm:
  qrySQLs.SQL.Text := Format('select Statement from SQLStatements where id = %d',[id]);
  qrySQLs.Open;
  Result := qrySQLs.Fields[0].AsString;
  qrySQLs.Close;
end;

oder:

Delphi-Quellcode:

const
  // Das einzige festverdrahtete Statement im Programm:
  csSQL = 'select Statement from SQLStatements where id = :id';

function dm.GetSQL(ID : Integer) : String;
begin
  qrySQLs.SQL.Text := csSQL;
  qrySQLs.Parameters('ID').Value := id;
  qrySQLs.Open;
  Result := qrySQLs.Fields[0].AsString;
  qrySQLs.Close;
end;

Irgendwo im Programm dann in etwa sowas:

Delphi-Quellcode:

procedure dm.HoleKundenDaten(KundenID : Integer);
begin
  qry.Close;
  qry.SQL.Text := GetSQL(1); // das SQL für die Kundendaten habe hier mal die ID 1.
  LabelSQLStatement.Caption := qry.SQL.Text; // Zum Angucken.
  Screen.Cursor := csSQLWait;
  qry.Open;

  ...

  qry.Close;
  Screen.Cursor := csDefault;
end;

Wenn man die SQLs in der Datenbank mit Parametern versieht, kann man sie in den Routinen gut mit Werten befüllen.

Weiterer Vorteil: Muss man mal die Datenbank wechseln, so kann man einfach die Statements in der Tabelle anpassen und muss nichts im Programm ändern.

Beim Wechsel von Access nach FireBird würde man dann z. B. aus dem Statement

SQL-Code:

select top 10 * from Tabelle

SQL-Code:

select first 10 * from Tabelle

machen. Das ist für's Programm selbst absolut transparent und spart auf Dauer viel Arbeit.

Hat man so auch SQLs für diverse Reports in der Tabelle liegen, kann man Reports auch anpassen, indem man nur das entsprechende Statement in der Tabelle ändert. Ist das Programm entsprechend flexibel aufgebaut, sind in ihm keinerlei Änderungen erforderlich.

Mit ein bisserl Aufwand läßt sich sowas wunderbar in 'nem Datenmodul kapseln (oder auch in 'ner entsprechenden Klasse).

Man baue eine Basisklasse und leitet von der dann Fachobjekte ab, die für die Befüllung der Parameter, entsprechend ihrer Eigenschaften zuständig sind ...

[himitsu]

Konstanten sollten überall gehn, auch solche in Klassen.
Aber meinst du wirklich Delphi 7 (wie du angegeben hast) und die Fehlermeldung hast du natürlich nicht genannt.

Bei Variablen sieht das anders aus, denn da können nur die Globalen einen vordefinierten Wert bekommen. :(

[edit] Links im Profil steht auch nochmal D7 :oops:
Nja, da wurde über die Jahre viel geändert, vorallem in Delphi 7, D2005 und D2006 wurde bezüglich Klassen-Variablen/Konstanten/Methoden so Einiges erweitert.
Aber ich hätte gedacht, dass es dennoch mit Arrays geht, also wenn es auch schon im D7 mit

Delphi-Quellcode:

const Test: Integer = 666;

funktioniert.

PS: Was hier vielleicht "wichtig" ist, denn für den Compiler sind "typisierte Konstanten" in Wirklichkeit "schrebgeschützte Variablen".

Delphi-Quellcode:

const Test = 666;  // "echte" Konstante
const Test: Integer = 666;  // schreibgeschützte Variable ala "var Test: Integer = 666;"

[Uwe Raabe]

Zitat:

Zitat von nahpets (Beitrag 1360955)

Einfach eine Tabelle in der Datenbank anlegen, die die SQL-Statements enthält. Jedes Statement bekommt 'ne ID, 'ne Beschreibung und natürlich das eigentliche SQL.

Damit verlagerst du aber einen Teil der Programmquellen (denn das sind SQL-Statements) in die Datenbank des Users. Vom Standpunkt einer konsistenten Versionsverwaltung ist das eher kritisch zu betrachten. Was würde denn passieren, wenn der User eine alte Datensicherung wieder einspielt? Das müsste das Programm erkennen und die SQL-Statements erstmal alle auf den passenden Stand bringen. Das gilt übrigens auch für das Einspielen einer älteren Programmversion. Das mag alles unter bestimmten Voraussetzungen funktionieren, aber ist es das wert?

[himitsu]

Und wo legt man das SELECT für den Zugriff auf diese SQL-Tabelle ab?
Auch in diese Tabelle? :lol:

Gut, wir haben "viele" SQLs auch in der DB, aber das ist eine synchronisierte Tabelle, wo man teilweise versionsabhängig aus einer/mehreren zentralen Synchro-Datenbank die aktuellen/passenden Daten runterladen kann/tut.
Vorallem ist es so möglich, dass man dort auch kundenspezifische Änderungen vornehmen kann.

[nahpets]

Zitat:

Zitat von Uwe Raabe (Beitrag 1360958)

Zitat:

Zitat von nahpets (Beitrag 1360955)

Einfach eine Tabelle in der Datenbank anlegen, die die SQL-Statements enthält. Jedes Statement bekommt 'ne ID, 'ne Beschreibung und natürlich das eigentliche SQL.

Damit verlagerst du aber einen Teil der Programmquellen (denn das sind SQL-Statements) in die Datenbank des Users. Vom Standpunkt einer konsistenten Versionsverwaltung ist das eher kritisch zu betrachten. Was würde denn passieren, wenn der User eine alte Datensicherung wieder einspielt? Das müsste das Programm erkennen und die SQL-Statements erstmal alle auf den passenden Stand bringen. Das gilt übrigens auch für das Einspielen einer älteren Programmversion. Das mag alles unter bestimmten Voraussetzungen funktionieren, aber ist es das wert?

Also dort, wo ich das für Kunden angewendet habe, gab es eine klare Trennung der Benutzerdaten und der Systemdaten. An den Systemdaten hat der User nichts zu suchen, das wurde ggfls. durch entsprechende Rechte geregelt. Bei Oracle z. B. ein eigenes Datenbankschema.

Benötigte der Kunde die Software für mehrere Mandanten, dann gab es das Systemschema mit eben dieser Tabelle und weiteren global gültigen Konfigurationsdaten und für jeden Mandanten ein eigenes Datenbankschema mit den Daten des Mandanten und ggfls. Konfigurationsdaten für diesen Mandanten.

Die Befüllung dieser Tabelle erfolgte immer aus den Datenbankscripten (mit denen auch die gesamte Tabellenstrukturen, Datenbankpackages ... - also als Teil des Datenmodells) ausgeliefert wurden. Und die wurden selbstverständlich mit in der Versionsverwaltung vorgehalten.

Zitat:

Zitat von himitsu

Gut, wir haben "viele" SQLs auch in der DB, aber das ist eine synchronisierte Tabelle, wo man teilweise versionsabhängig aus einer/mehreren zentralen Synchro-Datenbank die aktuellen/passenden Daten runterladen kann/tut.
Vorallem ist es so möglich, dass man dort auch kundenspezifische Änderungen vornehmen kann.

Im Prinzip halte ich das ähnlich. Auch wenn es technisch möglich ist, dass der User selbst daran "rumbastelt", wir haben das eigentlich immer so gehandhabt, dass individuelle Änderungen von der Administration eingepflegt wurden oder eben (der Normalfall) von uns so ausgeliefert wurden.

Einfach nur mal so eben rumbasteln darf ich nur bei der Software, die ich für mich selbst schreibe und die ich mir dann selbst zerschieße.

Habe da mal 'ne Software geschrieben, die musste gegen dBase, MSSQL, Interbase und Oracle laufen. Auf diese Weise habe ich im Programm nur das Statement für das Auslesen der Statements gehabt. Das kann man so einfach halten, dass es gegen alle Datenbanken läuft. Die übrigen Statements wurden entsprechend den unterschiedlichen Datenbanken syntaktisch angepasst und der Kunde hat die für "seine" Datenbank erforderliche Version ausgeliefert bekommen. Aber alle Kunden haben das gleiche Programm bekommen, da dort keine Anpassungen erforderlich waren.

[Mavarik]

Zitat:

Zitat von nahpets (Beitrag 1360938)

Suchst Du nach sowas in der Art?

Delphi-Quellcode:

const
  MaxText = 5;

type
  tSQLTexte = array[0..MaxText] of string;
const
  sqltexte : tSQLTexte = (
    'select * from Tabelle',
    'insert into Tabelle where id = :id',
    'delete from Tabelle where id = :id',
    'select * from Tabelle where id = :id',
    '...',
    '...');

Mein Delphi 7 kompiliert das.

Ok Vielleicht nicht mit Delphi 7 aber wie wäre es mit:

Delphi-Quellcode:

type
  TMyDatenWhatever = class
    private
     [ DefaultValue( 'select * from <Table>' ) ]
     FSQLSelect : String;
     [ DefaultValue( 'insert into <Table> (<Fields>) VALUES (<Values>) where id = :id' ) ]
     FSQLInsert : String;
     [ DefaultValue( 'UPDATE <Table> <SETS> where id = :id' ) ]
     FSQLUpdate : String;
     [ DefaultValue( 'delete from <Table> where id = :id' ) ]
     FSQLDelete : String;
   // ...
  end;

Habs zwar noch nie so gemacht... aber ok...

Mavarik