Übergabe Datenbankschnittstelle (Transaction, etc.)

[Artur]

Hallo Folks,

gutes neues Jahr (Glück, Gesundheit und spannende Projekte...)

Ich habe mal eine Frage zum guten Programmierstil bei Datenbankanwendungen. Ich habe ein Vertriebsprogramm für unsere Firma, dass immer wieder erweitert wird.
Inzwischen bin ich dazu übergegangen, einige Sachen in eigene kleine Programme auszulagern oder neue Module erst mal eigenständig zu entwickeln und später ins Programm einzusetzen. Ich arbeite mit dem Firebird Embedded Server auf unseren Außendienst-Laptops und der echten Server Version auf unseren Firmenservern.
Die Laptops haben eine lokale Datenbankdatei, die mit den Servern repliziert wird.

Meine Frage: Wie würde man am saubersten die Datenbank(Anbindung) zwischen den Modulen / einer Bibliothek übergeben?

Ein Beispiel: Die Routine unten soll das Ergebnis (z.B. Fehlermeldungen) eines SQL-Skriptes in die Datenbank schreiben. Die Routine war im Hauptprogramm und soll nun in einem anderen Tool auch verwendet werden, also wäre es sinnvoll das Ganze in eine Art Bibliothek zu verschieben. Würdet ihr eine Transaction übergeben (und dann die Query dynamisch erzeugen?). Oder die Datenbankkomponente übergeben (oder nur den Datenbanknamen, was beim Embedded Server inzwischen mit einer lokalen Datei auch klappt, solange beide Programme auf den gleichen Embedded zugreifen).

Was wäre hier ein guter Stil?
Und kann jemand eine gute Literatur empfehlen, wie die oft geforderte Trennung zwischen Datenbank, Businesslogik und grafische Darstellung aussehen sollte?


Vielen Dank im voraus,

Artur

Delphi-Quellcode:

procedure TReplicatorForm.WriteSQLMessageToDB(MsgText : string);
var
  TextFile : TStringList;
  TextFileName : string;
  FS : TFormatSettings;
begin
  try
    if not trClntWr.InTransaction then trClntWr.StartTransaction;
    with quClnt2 do
    begin
      SQL.Clear;
      SQL.Add(' INSERT INTO SQL_MESSAGE ');
      SQL.Add(' (DB_VERSION, MSG_FROM_PROCEDURE, MSGTEXT, PROG_VERSION, HOST_ID, PC_NAME) ');
      SQL.Add(' VALUES ');
      SQL.Add(' (:DBVersion, :FromProcedure, :MsgText, :ProgVersion, :HostID, :PCName)' );
      ParamByName('DBVersion').AsString := FClntDBVersion;
      ParamByName('FromProcedure').AsString := 'TReplicatorForm';
      ParamByName('MsgText').AsString := Copy(MsgText,1,12000);
      ParamByName('ProgVersion').AsString := Opts.VersionInfo;
      ParamByName('HostID').AsString := FClientID;
      ParamByName('PCName').AsString := Opts.DBHostName;
      ExecQuery;
    end;
    trClntWr.Commit;
  except
    TextFile := TStringList.Create;
    try
      FS := TFormatSettings.Create('de-DE');
      FS.DateSeparator := '.';
      FS.TimeSeparator := '-';
      TextFile.Add(MsgText);
      TextFileName := GetIniFilePath + '\RepLog_' + DateTimeToStr(Now,FS) + '.txt';
      TextFile.SaveToFile(TextFileName);
    finally
      TextFile.Free;
    end;
  end;
end;

[nahpets]

Hallo Artur,

in so einem Fall würde ich die gesamten Datenbankzugriffe in ein Datenmodul legen und dieses Datenmodul in alle Programme einbinden. Dadurch kannst Du dann die gesamte Datenbankschnittstelle in diesem Modul pflegen, die Änderungen sind aber in allen Programmen beim nächsten Kompilieren vorhanden. Eventuelle "Quelltextredundanzen" (also (annähernd) identische Quelltextteile in verschiedenen Formularen... können entfallen).

Deine Prozedur procedure TReplicatorForm.WriteSQLMessageToDB(MsgText : string); würde dann mit dem gesamten Inhalt z. B. zu procedure TDatenmodulVertrieb.WriteSQLMessageToDB(MsgText : string); Eventuell machst Du aber aus der Prozedur eine Funktion, damit Du im aufrufenden Programm... den Erfolg oder Misserfolg abfragen kannst:

Delphi-Quellcode:

function TDatenmodulVertrieb.WriteSQLMessageToDB(MsgText : string) : Boolean;
var
  TextFile : TStringList;
  TextFileName : string;
  FS : TFormatSettings;
begin
  Result := false; // Wir gehen erstmal von einem Misserfolg aus.
  try
    if not trClntWr.InTransaction then trClntWr.StartTransaction;
    with quClnt2 do
    begin
      SQL.Clear;
      SQL.Add(' INSERT INTO SQL_MESSAGE ');
      SQL.Add(' (DB_VERSION, MSG_FROM_PROCEDURE, MSGTEXT, PROG_VERSION, HOST_ID, PC_NAME) ');
      SQL.Add(' VALUES ');
      SQL.Add(' (:DBVersion, :FromProcedure, :MsgText, :ProgVersion, :HostID, :PCName)' );
      ParamByName('DBVersion').AsString := FClntDBVersion;
      ParamByName('FromProcedure').AsString := 'TReplicatorForm';
      ParamByName('MsgText').AsString := Copy(MsgText,1,12000);
      ParamByName('ProgVersion').AsString := Opts.VersionInfo;
      ParamByName('HostID').AsString := FClientID;
      ParamByName('PCName').AsString := Opts.DBHostName;
      ExecQuery;
    end;
    trClntWr.Commit;
    Result := True; // Erfolgreich sind wir nur, wenn wir das Commit "überstanden" haben.
  except
    TextFile := TStringList.Create;
    try
      FS := TFormatSettings.Create('de-DE');
      FS.DateSeparator := '.';
      FS.TimeSeparator := '-';
      TextFile.Add(MsgText);
      TextFileName := GetIniFilePath + '\RepLog_' + DateTimeToStr(Now,FS) + '.txt';
      TextFile.SaveToFile(TextFileName);
    finally
      TextFile.Free;
    end;
  end;
end;

Der Aufruf in Deinen Programmem könnte dann in etwa so aussehen:

Delphi-Quellcode:

procedure TReplicatorForm.WriteSQLMessageToDB(MsgText : string);
begin
  if not DatenmodulVertrieb.WriteSQLMessageToDB(MsgText) then begin
    ShowMessage('Die Meldungen konnten leider nicht geschrieben werden.');
    // Oder halt irgendwelche sonstigen Fehlerbehandlungen, sofern erforderlich.
  end;
end;

Im Idealfall erfolgt eine strenge Trennung zwischen den Datanbankroutinen und der optischen Darstellung der Daten und der übrigen Geschäftslogik.

Im Extremfall könntest Du dann durch Austausch des Datenbankmoduls ohne Änderungen an den übrigen Programmen auf die Datenbank eines anderen Herstellers wechseln, sofern nicht alle Datenbankzugriffe für alle Datenbanken kompatibel sein sollten.

Letztlich entsteht durch das Datenmodul ein eigenes Objekt bzw. eine Klasse zur Verfügung, die die gesamte Datenbankschnittstelle kapselt. Hierdurch lassen sich Redundanzen (annähernd) identischer Quelltext in vielen Programmen, Formularen, Units... vermeiden. Der anfänglische Mehraufwand für das Design des Datenmoduls lohnt sich bei der weiteren Entwicklung und Pflege der Software sehr schnell.
Jedes neue Programm oder Modul verfügt alleine durch das Einbinden des Datenmoduls sofort über die komplette Datenbankschnittstelle.

Zugegeben: So eine Schnittstelle nachträglich in bereits bestehende Programme und Module einzubauen ist eine Herausforderung und erfordert eine grundlegenden Analyse des Vorhandenen und einer fundierten Planung. Aber der Aufwand kann sich durchaus (auch oder gerade bei noch wachsenden Projekten) lohnen.

[sx2008]

Der Codeblock unterhalb von Except gehört eigentlich in eine eigene Procedure:

Delphi-Quellcode:

procedure TDatenmodulVertrieb.SaveMessageToLogfile(MsgText : string);
var
  TextFile : TStringList;
begin
    TextFile := TStringList.Create;
    try
      TextFile.Add(MsgText);
      TextFileName := GetIniFilePath + '\RepLog_' + FormatDateTime('yyyy-mm-dd hh.nn.ss', Now) + '.txt';
      TextFile.SaveToFile(TextFileName);
    finally
      TextFile.Free;
    end;
end;

Man beachte auch das Datumsformat das mit dem Jahr beginnt.
So kann man die Dateien nach Namen sortiert anzeigen und bekommt gleichzeitig eine Sortierung nach Datum.

[Sir Rufo]

Es ist kein guter Stil pauschal alle Exceptions zum Loggen abzufangen, denn das ist keine Behandlung von Exceptions, sondern Unterdrückung (ok, mit speichern).

Wenn du Exceptions loggen möchtest, dann lass die einfach durchrauschen und erledige das Loggen im TApplication.OnException Event mit einer Routine (DRY).

Eine Exception-Behandlung macht nur dann Sinn, wenn es dafür auch eine sinnvolle Behandlung gibt, wenn es da noch was zu retten gibt.

[Furtbichler]

Zitat von Sir Rufo:

Wenn du Exceptions loggen möchtest, dann lass die einfach durchrauschen und erledige das Loggen im TApplication.OnException Event mit einer Routine (DRY).

Das ist etwas zu DRY.

Vielleicht ein wenig richtiger ist: in jeder Schicht (Transport, Datenbank, Business, View, UI) sollten die Exceptions abgefangen und geloggt werden. Anschließend werden sie interpretiert und für den Aufrufer verständlich weitergeleitet. Es interessiert die Business-Schicht nicht, das der Transport aufgrund eines TCP-Stackfehlers nicht funktioniert oder ein Deadlock eingetreten ist, oder der FK falsch ist (aua!). Er funktioniert nicht und fertig. Die Datenbankschicht muss alle Exceptions der Transportschicht abfangen, ggf. Reparaturmaßnahmen einleiten (nochmal probieren z.B.) und als 'EDatabaseException' weiterleiten. Da hat man dann eine gewisse Redundanz, aber eigentlich ist das keine, denn das ist ein 'Pattern' (Sonst würdest du bei jeder For-Schleife ja auch 'DRY' schreien). Also vielleicht so:

Delphi-Quellcode:

Procedure TMyLayer.MyPublicMethod();
Begin
  While true do
    Try
      SubLayer.DoInternalStuff();
      Break;
    Except
      On E:EMyLayerException do begin
        LogException('MyLayer','MyPublicMethod',E);
        Raise E;
      end;
   
      On E:ESubLayerException Do
        If Not ExceptionIsReparable(E) then
          Raise EMyLayerException.Create(E);

      On E:Exception Do begin
        LogFatal('MyLayer','MyPublicMethod',E);
        Raise EMyLayerException.Create(E);
      end;
    End
  End
End;

Natürlich kann die Exceptionbehandlung besser aussehen (Verhindern unendlicher Wiederholversuche z.B.), aber es geht hier ums Prinzip: Jede Schicht loggt die eigenen und unvorhergesehene Exceptions. Alle werden interpretiert und weitergeleitet, wenn sie nicht repariert werden können.

Das wird in jeder Schicht entsprechend umgesetzt (so viele sind es ja nicht). Vorteil: 'MyLayer' muss sich nur um eigene sowie die Exceptions kümmern, die vom 'SubLayer' geworfen wurden. Alles andere sind schwere Vergehen und dürfen nicht auftreten (natürlich werden sie entsprechend behandelt).

Dieses Pattern kann man auch über Prozedurvariablen DRY-Technisch aufbessern, sodaß die entsprechende Exceptionbehandlungslogik nicht zu oft wiederholt wird. Allerdings ist es ausnahmsweise auch erlaubt, hier auf DRY zu verzichten, denn die individuelle Exceptionbehandlung, Konfliktauflösung usw. ist im Einzelfall doch unterschiedlich.

Im Idealfall hat man hier zwei Klassen pro Schicht: Eine reine Arbeitsklasse, die die Logik enthält und ausführt (mit den public Methoden A, B und C. Diese Klasse ist nach außen hin nicht sichtbar. Darüber stülpt man die Klasse, die sichtbar ist, und für jede Public Methode (A,B,C) die Exceptionbehandlung durchführt. So kann man einerseits die Logik testen und andererseits den Exception/Securitywrapper.

Hier kann es sinnvoll sein, viele einzelne Logik/Businessklassen zu haben, jedoch nur eine 'Schnittstelle nach außen', nämlich den Securitywrapper, aber das muss im Einzelfall entschieden werden.

Alternativ gibt es noch die Möglichkeit, die Exceptions abzufangen, zu interpretieren, zu verpacken (wenn sie nicht aufgelöst werden können) und weiterzuleiten, also ohne Logging (Sieht man leider immer wieder). Aber davon halte ich nichts, denn Exceptions werden ja doch abgefangen und verschluckt (Deadlock-Problematik beim DB-Layer, Verbindung bricht ab, kann aber wieder hersgestellt werden z.B.). Genau die will ich aber loggen. Das geht dann nicht, wenn alles bis kurz unter die Oberfläche gespült wird.

[Artur]

Guten Morgen,

und vielen Dank für die sehr ausführlichen Antworten

@sx2008: Danke für den Hinweis, werde ich ändern

@nahpets: Aus dem Ansatz komme ich eigentlich her. Ich hatte ein Datenmodul mit den Kopplungen zur Datenbank, etc. Dann kam ein Datenmodul dazu, mit einigen Optionen für das Hauptprogramm. Dann habe ich einen Kalender ergänzt, den ich aber erst mal eigenständig gebaut habe. Deshalb hat der sein eigenes Datenmodul. Und da wäre die Frage, wie man die am Besten miteinander koppelt bzw. was man am sinnvollsten übergibt (beim Kalender hatte ich die TpFIBDatabase als Parameter übergeben).

@Sir Rufo: Mein Exceptionhandling im Programm ist generell grausam und ab und zu versuche ich alten Code dahingehend auch zu bereinigen. Ursprünglich hatte ich es so, dass alles durch gewunken wurde, damit die Mitarbeiter nirgend festhängen (FIBplus hat einen Exceptionhandler als Komponente). Inzwischen bin ich das eher am rückbauen, weil ich nicht mehr weiß, wo der Fehler aufgetreten ist. Die Prozedur unten wird nur an zwei Stellen verwendet: Bei der Replikation und wenn ich eine neue Version verteile, und an der lokalen Datenbank ein paar Änderungen über Skript durchgeführt werden müssen. In beiden Fällen kann ich nichts groß behandeln:

- Replikationsfehler heißt in der Regel Abriss der Datenbankconnection zum Server, dann muss der AD halt die Replikation insgesamt neu starten.
- Und meine Update Skripte hatten zuletzt immer wieder mal Fehler ausgeworfen, wenn z.B. eine Domain schon angelegt war. Beim Update wurde gemeldet, dass irgendetwas schiefgegangen ist, aber die Leute können damit nichts anfangen und in der Regel war es nicht kritisch und das Programm lief trotzdem soweit okay.
Inzwischen gibt es aber bedingte Skripte bei FIBplus, da bin ich gerade am lernen, ob ich diese Domain Geschichten sauber wegbekomme. Und generell will ich Datenbankupdates irgendwann beim Datenabgleich durchführen und dieses blöde Patchen bei Updates loswerden.

Ich wollte mir mit der Routine nur die Chance schaffen, nachträglich nachschauen zu können, was da evtl. nicht geklappt hat.

@Furtbichler: Öhmmm... (Sehr interessant, ein wenig hoch für meine begrenzten Fähigkeiten, werde ich mal sacken lassen...).

Vielen Dank an alle,

Artur

[nahpets]

Zitat von Artur:

@nahpets: Aus dem Ansatz komme ich eigentlich her. Ich hatte ein Datenmodul mit den Kopplungen zur Datenbank, etc. Dann kam ein Datenmodul dazu, mit einigen Optionen für das Hauptprogramm. Dann habe ich einen Kalender ergänzt, den ich aber erst mal eigenständig gebaut habe. Deshalb hat der sein eigenes Datenmodul. Und da wäre die Frage, wie man die am Besten miteinander koppelt bzw. was man am sinnvollsten übergibt (beim Kalender hatte ich die TpFIBDatabase als Parameter übergeben).

Meiner Meinung nach gehören allen Zugriffskomponenten für die Datenbank(en) in das Datenbankmodul. D. H.: Die anderen Module, Formulare... kennen die Datenbank(en) nicht, sie "wissen" nicht einmal, dass sie irgendwelche Daten von einer Datenbank erhalten.

Wenn Du mehrere Datenbanken benötigst, dann kapsle jede Datenbank in einem eigenen Datenmodul, sofern ansonsten die Übersichtlichkeit in einem Datenmodul darunter leiden sollte.

Meist gehe ich her und halte alle SQL-Statements in einer Datenbanktabelle vor. Diese kann sich unter Umständen in einer eigenen Datenbank befinden, welche zur Steuerdaten enthält. Die "Nutz"-Daten befinden sich in einer eigenen Datenbank. Hierdurch lässt sich sehr einfach eine Mandantenfähigkeit realisieren. Alle nutzen gemeinsam die Datenbank mit den Steuerdaten, jeder Mandant hat seine eigene Nutzdatendatenbank. Steuerdatenbank und Nutzdatenbanken können sich dabei auf unterschiedlichen Datenbankservern befinden, z. B. ein Server für die Steuerdatenbank und ein Server für die Nutzdatenbanken, aber auch für jede Nutzdatenbank ein eigener Datenbankserver ist möglich. Was wo liegt uss hierbei natürlich (z. B. über eine INI-Datei) konfigurierbar sein. Bei mir gilt, wenn möglich, die Regel: Keine feste Verdrahtung der Datenbankverbindungen im Programm. Alles irgendwie sinnvoll und einfach (d. h.: anwender- und administrator- und entwicklerfreundlich - in dieser Reihenfolge) konfigurierbar halten.

Die SQL-Statements sind, sofern erforderlich, parametrisiert. Jedes SQL hat eine eindeutige ID. Werden nun (von wem auch immer) Daten aus der Datenbank benötigt, so erhält eine entsprechende Funktion im Datenmodul eine Anfrage.

Das einzige im Quelltext "festverdrahtete" SQL-Statemant ist das Statement zum Holen der SQL-Statements. Beim Wechsel des Datenbankherstellers muss ich daher nur die SQL-Statements in der Datenbanktabelle (sofern erforderlich) syntaktisch an die ggfls. geänderten Bedingungen oder die andere Syntax anpassen. Am Programm sind keine Änderungen erforderlich. Hierdurch konnte ich vor Jahr und Tag mal eine recht komplexe und mandantenfähige Anwendung ohne Änderungen am Quellcode von DBase über Interbase und Oracle nach schließlich MS-SQL-Server portieren. (Damals war die Nutzung der BDE noch selbstverständlich). Irgendwann musste ich dann den Datenbankzugriff auf die ADO-Komponenten umstellen. Hier waren dann nur Änderungen am Datenmodul notwendig.

Wie Du die Parameter für die Wherebedingungen... übergibst, muss Du selbst entscheiden. Hier fallen mir zwei bis drei Möglichkeiten ein:

Als Parameterliste an eine oder mehrere Funktionen des Datenmoduls. Dies kann recht schnell aufwändig werden.

Das Datenmodul "beauftragen" ein bestimmtes SQL aus der Datenbanktabelle zu holen, dann im Modul, Formular... die Parameter befüllen, Das Datenbankmodul um Ausführung der Abfrage bitten und anschließend selbst das Ergebnis verarbeiten.

Mal nur so ungetestet hingedaddelt:

Delphi-Quellcode:

begin
  ...
  if Datenmodul.GetSQL(SQLID) then begin
    Datenmodul.AbfrageQuery.Parameters.ParamByName('Termin').Value := FTermin;
    ... was auch immer benötigt werden sollte
    ... Value ist vom Typ Variant, so dass hier nicht auch noch mit .AsIrgendwas gearbeitet werden muss
    Datenmodul.AbfrageQuery.Parameters.ParamByName('Name').Value := FName;
    If Datenmodul.OpernQuery then begin
      // Die Daten der Abfrage in eigene Attribute, die Anzeige... übernehmen.
      FTermin := Datenmodul.AbfrageQuery.FieldByName('Termin').Value;
      ...
    end else begin
      // Hier ordentliche Fehlerbehandlung für den Fall, dass das Öffnen der Abfrage scheiterte.
    end;
  end else begin
    // Hier natürlich dann eine sinnvollere Fehlerbehandlung.
    // Allerdings darf in einer durchgetesteteten Programmversion dieser Fehler niemals
    // auftreten, wenn doch, haben entweder der Programmierer oder der Datenbankadministrator
    // Haue verdient.
    ShowMessage(Format('Das SQL mit der ID %d konnte nicht gefunden werden.',[SQLID])); 
  end;
...
end;

Für Insert, Delete und Update eine entsprechende Routine bauen, die dann kein OpenQuery macht sondern ein ExecSQL macht.

Alle direkten Datenbankzugriffe werden vom Datenmodul ausgeführt. Dieses behandelt alle Datenbankfehler und gibt, wenn nicht vermeidbar, anwenderfreundliche Fehlermeldungen zurück. Der Programmablauf sollte auch im Fehlerfalle störungsfrei weitergehen.

Alternative:

Eine Basisklasse erstellen, die alle Datenbankzugriffe kapselt. Alle Daten aus der Datenbank werden über abgeleitete Klassen verwaltet. Bei Änderungen an der Datenbank sind nur Änderungen in der Basisklasse erforderlich. Alle direkten Zugriffe auf die Datenbank sind in Funktionen dieser Basisklasse (einschließlich Fehlerbehandlung) gekapselt.

Welche Variante hier nun sinnvoll sein könnte, vermag ich nicht zu entscheiden, dafür fehlen zu viele Informationen über Art und Komplexität der Anwendung, da müsste man sich wohl die fachliche und die technische Seite erstmal das eine oder andere Stündchen grundlegen anschauen. Die grundsätzlich immer beste Lösung gibt es wohl nicht .