Datenbankanbindung in einer Klasse

[Jens Hartmann]

Hallo zusammen,

ich hab mal wieder ein gedankliches Problem. Ich habe meine erste kleine eigene Klasse zum Parsen von Ereignissen geschrieben. Irendwie bin ich allerdings zur Zeit am Grübbeln, ob das alles so OK ist, was ich da zusammen bastel.

Eigendlich benötige ich in dieser Klasse jetzt Daten, die in einer DB gespeichert sind. Daher mal meine Frage, es ist ja keine Problem, in dieser Klasse jetzt auf meine Datenmodul zu zugreifen. Allerdings könnte ich die Klasse ja dann schon nicht mehr in einem anderen Programm verwenden.

Ist das Grundsätzlich OK, und habe ich da einen Denkfehler.

Muss ich eventuell diese Daten z.B. als StringList schon an die Klasse übergeben ? Dann wiederum weiß ich nicht, ob die Klasse noch so richtig sinnvoll ist, oder ob ich die 10 Funktion, dann besser im Programm selber als privat implementiere.

Ich hoffe ich konnte kurz beschreiben, was ich wissen möchte.

Danke und Gruß

Jens

[H4ndy]

Du koenntest eine Grundklasse schreiben, welch die Daten verarbeitet, und dann fuer bestimmte Datenbanken einen spezifische Klasse ableiten, welche z.B. das passenden Datenmodul entgegen nehmen kann.

[DeddyH]

Das hört sich für mich so an, als ginge das in Richtung object persistence framework.

[Jens Hartmann]

Hallo H4andy,

das habe ich auch schon überlegt. Die Frage ist nur, macht das alles Sinn. Ich denke, das die Klasse niemals jemand anderem was nutzen wird, da sie einfach zu speziell ist. Und ob ich Sie nochmal brauche, glaube ich nicht. Daher, hätte ich eigendlich keine Bauchschmerzen mit dem Datenmodul.

Ich habe nur überlegt, weil ich so langsam anfangen OO zu Porgrammieren und es auch so langsam verstehe und da sagt halt mein Verstand,wenn OO, dann auch nutzbar immer etc.

Allerdings, kam der Grundgedanke eine eigene Klasse einzusetzen, aus lerntechnischer Anforderung und um einige Funktion aus dem Quellcode auszulagern.

Da ich aber in diesen ausgelagerten Funktionen auch Daten aus der DB benötige, stehe ich halt jetzt vor diesem Problem.

Ich zeige mal den aktuellen Stand, vieleicht schlagt Ihr dann eh die Hände über dem Kopf zusammen....

Delphi-Quellcode:

Unit EventUtils;

interface

uses
  Windows,SysUtils,Classes,Dialogs, Datenbankanbindung;

type
  TMyEventParser = class
  private
    procedure GetParamsOfGServer(var Params : TStringList);
    procedure SetDisplayTextOn(Text : String);
  public
    function EventParseSetDisplay(EventList : TStringList; Event : String) : Boolean;
    function EventParseMakeCall(EventList : TStringList; Event : String) : Boolean;
    function EventParseClearDisplay(EventList : TStringList; Event : String) : Boolean;
  end;

implementation

{Prüft das aktuelle Ereignis auf Übereinstimmung bzw. den Inhalt der StringListe
 der gesamten Ereignisstrings des Gefahrenmeldesystems.
 Das Ergebnis führt die Funktion SetDisplayText aus}
function TMyEventParser.EventParseSetDisplay
  (EventList: TStringList; Event : String ) : Boolean;
var
  i : integer;
  DisplayText : String;
begin
  try
    Result := false;
    if EventList.IndexOf(Event) <> -1 then
      begin
        for i := 0 to EventList.Count - 1 do
          DisplayText := DisplayText + EventList[i];
        SetDisplayTextOn(DisplayText);
        Result := true;
      end;
  except
    Result := false;
  end;
end;
{Prüft das aktuelle Ereignis auf Übereinstimmung bzw. den Inhalt der StringListe
 der gesamten Ereignisstrings des Gefahrenmeldesystems.
 Das Ergebnis führt die Funktion MakeCall aus}
function TMyEventParser.EventParseMakeCall
  (EventList: TStringList; Event : String ) : Boolean;
var
  i : integer;
begin
  try
    Result := false;
    if EventList.IndexOf(Event) <> -1 then
      Result := true;
  except
    Result := false;
  end;
end;
{Prüft das aktuelle Ereignis auf Übereinstimmung bzw. den Inhalt der StringListe
 der gesamten Ereignisstrings des Gefahrenmeldesystems.
 Das Ergebnis führt die Funktion ClearDisplayText aus}
function TMyEventParser.EventParseClearDisplay
  (EventList: TStringList; Event : String ) : Boolean;
var
  i : integer;
begin
  try
    Result := false;
    if EventList.IndexOf(Event) <> -1 then
      Result := true;
  except
    Result := false;
  end;
end;

procedure TMyEventParser.SetDisplayTextOn(Text: string);
var
  slParams: TStringList;
  Cookie : String;
begin
  try
    slParams := TStringList.Create;
    GetParamsOfGServer(slParams);
    Dm_PS.idHttpGServer.Post('http://127.0.0.1:8801/login', slParams);
    Cookie:= DM_PS.idCookieGServer.CookieCollection.Items[0].CookieText;
    DM_PS.idHttpGServer.Request.CustomHeaders.Add('Cookie:' + Cookie);
    ShowMessage(Text);
  finally
    slParams.Free;
  end;
end;

procedure TMyEventParser.GetParamsOfGServer(var Params : TStringList);
begin
  Params.Add('gsUser=admin');
  Params.Add('gsPass=adminpass');
end;

end.

:gruebel: :gruebel: :gruebel: :gruebel: :gruebel: :gruebel: :gruebel:

Gruß Jens

[DeddyH]

Zum Quellcode sag ich jetzt mal nichts, aber das sieht mir nicht so aus, als ob die Klasse primär mit DB-Zugriff zu tun hat. Von daher würde ich falls notwendig einfach Properties dieser Klasse deklarieren, die die Daten aufnehmen. Woher diese Daten dann kommen, ist für die Klasse selbst irrelevant, das kann eine DB oder sonstwas sein.

[Jens Hartmann]

Die Funktion, die Daten aus der DB benötigen, fehlen ja auch noch. In einer bislang vorhanden, habe ich die Daten zur Zeit einfach eingetragen.

Delphi-Quellcode:

procedure TMyEventParser.GetParamsOfGServer(var  Params : TStringList);
begin
  Params.Add('gsUser=admin');
  Params.Add('gsPass=adminpass');
end;

Die Benutzerdaten, sind natürlich in einer DB gespeichert. Oder...

Delphi-Quellcode:

    GetParamsOfGServer(slParams);
    Dm_PS.idHttpGServer.Post('http://127.0.0.1:8801/login', slParams);

hier greife ich über DM_PS. schon auf meine Datenmodul zu. Und beim erstellen, ist mir halt dieses Problem jetzt aufgefallen.

Was heißt eigendlich, zum Code sage ich nichts. Nicht gelesen, oder Sche...?

Gruß Jens

[DeddyH]

Nicht unbedingt Sch..., aber ein paar Flüchtigkeitsfehler sind schon drin. Und ich würde dann nicht fix auf das Datenmodul zugreifen, sondern mir ein Event samt Ereignisroutine definieren. Dann kannst Du von "außerhalb" sagen, was passieren soll, wenn das Event eintritt (siehe z.B. Komponenten, die machen das ja auch so).

[Jens Hartmann]

Ja, aber ganau da habert es bei mir noch. Wenn Du übrigens die Exceptionbehandlungen und so meinst, die habe ich noch nicht geschrieben. Ich habe heute erst mit der Klasse angefangen.

Gruß Jens

[DeddyH]

Nein, was ich meine (ein Beispiel):

Zitat:

Delphi-Quellcode:

procedure TMyEventParser.GetParamsOfGServer(var  Params : TStringList);
begin
  Params.Add('gsUser=admin');
  Params.Add('gsPass=adminpass');
end;

TStringlist ist eine Klasse, es wird also eine Instanz übergeben. In den allermeisten Fällen macht es keinen Sinn, diese als Var-Parameter zu deklarieren, es sei denn, man wollte diese Instanz innerhalb der Routine neu zuweisen. Ich würde das so schreiben:

Delphi-Quellcode:

procedure TMyEventParser.GetParamsOfGServer(Params : TStrings);
begin
  if Assigned(Params) then
    begin
      Params.Add('gsUser=admin');
      Params.Add('gsPass=adminpass');
    end;
end;

[Alfredo]

Zitat:

Ich habe nur überlegt, weil ich so langsam anfangen OO zu Porgrammieren und es auch so langsam verstehe und da sagt halt mein Verstand,wenn OO, dann auch nutzbar immer etc.

Mein persönlicher Rat: lass es.

Ich durfte mich ein Semester mit dem OO beschäftigen und am Ende, als ich es so richtig
verstanden hatte, hat der Professor dann zugeben müssen, dass die verwendete Sprache(Java)
nicht zu 100% für OOP geeignet ist.

Meines Erachtens steht der Aufwand für ein kleiners Unternehmen in keinen Verhältnis
zum Ertrag. Schau Dir so eine Programmierung nach ein paar Tagen wieder an. Du bekommst
die Krise. Versprochen.

Ein wirklicher EDV-Profi hat mir einmal geraten es bei einfachen Unterprogrammen zu be-
lassen und dort jede Menge an Debugcode für den Fehlerfall zu implementieren. Das geht
bei dem soweit, dass der größte Teil Debugcode ist. Er musste dafür schon etliche Kritik
vom Kunden einstecken. Die meisten sagen heute keinen Ton mehr, weil der Ernstfall einge-
treten und die Fehlerbehebung in sehr kurzer Zeit erfolgt ist.

Gruß
Alfred