[Erledigt] Mehrfachverwendung von Code.

[charlytango]

Hi,

für meine quasi allgemeine Anbindung an SQL Datenbanken habe ich je ein Datenmodul für SQLDB und ZEOS und eine Unit in der ein Zugriffsobjekt zur Laufzeit erstellt wird.

Nun ist sehr viel Code (ggfs mit keinen Änderungen) in allen drei Units gleich.
Klar kann man versuchen möglichst viele der Funktionen und Prozeduren und eine eigene Unit auszulagern, aber immer gelingt das nicht oder nicht gut.

Des weitern kann man versuchen, mit include Dateien zu arbeiten wobei das immer wieder ein Gefrickel mit den Funktions-Deklarationen und den Funktionsrümpfen ist. (oder ich habe es nicht wirklich durchschaut)

Jetzt bin ich aber kein Pascal-Guru der die Sprache bis ins letzte Eck kennt.
Daher meine Frage ob es irgend eine andere elegante Methode gibt, die ich übersehen habe?

Soweit das ohne Beispielcode möglich ist.

PS: da kommt dann noch ein Aspekt dazu -- nachdem das Package auch für jemanden gedacht ist, der viellciht noch an seinen ersten Schritten in die DB-Anbindung arbeitet, sollte das Ergebnis idealerweise auch recht gut zu verstehen sein. Solche Konstrukte sind da vielleicht nicht wirklich übersichtlich:

Code: Alles auswählen

  private
    {$DEFINE read_interface_private}
    {$include dmsqldb.inc}
    {$UNDEF read_interface_private}

  public
    {$DEFINE read_interface_public}
    {$include dmsqldb.inc}
    {$UNDEF read_interface_public}

  end;


var
  dmsqldb: Tdmsqldb;
  {$DEFINE read_var}
  {$include dmsqldb.inc}
  {$UNDEF read_var}

[theo]

Ich weiss nicht, ob man dazu in dieser Allgemeinheit viel sagen kann.
Möglicherweise könnte man eine Basisklasse machen, wo alle gemeinsamen Methoden enthalten sind.

Klar kann man versuchen möglichst viele der Funktionen und Prozeduren und eine eigene Unit auszulagern, aber immer gelingt das nicht oder nicht gut.

Warum denn nicht? "Möglichst viele" sollte doch immer gehen und wenn's nur eine ist.

[af0815]

Egal was du machst, es wird nicht übersichtlicher.

Es geht bis zu einem gewissen Grad, wenn man mit bedingter Kompilierung arbeitet. Ich habe das am Anfang mit SQLDB und ZEOS gemacht. Je nachdem was ich bei der Kompilierung angegeben habe, das hat es verwendet. Geht gerade noch, wenn man das im Datenmodul kapseln kann, wenn die bedingte Kompilierung quer über etliche Units verstreut ist, wird es unübersichtlich, besonders, wenn man viel Code wiederverwendet.
Beispiele:

Code: Alles auswählen

type
  // Für Kompatibilität
  {$ifdef useZEOS}
  TAFConnection = TZConnection;
  TAFQuery = TZQuery;
  {$else}
  TAFConnection = TMSSQLConnection;
  TAFQuery = TSQLQuery;
  {$endif}


  { TDataModule1 }

  TDataModule1 = class(TDataModule)
    procedure DataModuleCreate(Sender: TObject);
  private
    FLocalTempFileName: string;
    SQLCon  : TAFConnection;
    {$ifdef useZEOS}
    {$else}
    SQLTransaction : TSQLTransaction;
    {$endif}
    end;
  
  ....
  function GetConnectionSQL: TDataModule1;
begin
  if (DMSql = nil) then begin
    DMSql := TDataModule1.Create(nil);
    DMSql.SQLCon.HostName:= coConnection;
    DMSql.SQLCon.{$ifdef USEZEOS}Database{$else}DatabaseName{$endif}:= coDatabase;
  end ;
  Result := DMSql;
end;
....
    {$ifndef useZEOS}aQuery.Options := [sqoAutoApplyUpdates,sqoAutoCommit];{$endif}
    DebugLn('TDMxxxxx.SQLStoreMessung DB='+SQLCon.{$ifdef USEZEOS}Database{$else}DatabaseName{$endif});
  
    

[charlytango]

Egal was du machst, es wird nicht übersichtlicher.

genau das ist aktuell mein Problem.

Die (produktive) Unit, bei der mit bedingter Kompilierung zwischen SQLDB und ZEOS unterschieden wird, habe ich im Griff. Das gibt dann eine Basisklasse auf die man eine bis zwei Schichten ableiten kann (um ZB speziell f eine Applikation nötige Sachen einzubauen) und alles was DB-Zugriff und deren Hilfsfunktionen benötigt, ist dort gut "eingesperrt".
So ein Konstrukt lässt sich auch gut als Singleton Objekt bauen und damit hat man es sofort im ganzen Programm zur Verfügung.

Das ist lang erprobte Praxis, weil es mit der Ableitung von Datenmodulen immer wieder Probleme gab (auch noch zu Delphis Zeiten und in Lazarus hat das auch nicht friktionsfrei geklappt)

Die Grundidee des Package war und ist aber, jmd der noch nicht viel Ahnung von DB Anbindung hat, schnelle Ergebnisse und den zugriff auf verschiedene Datenbanken zu ermöglichen.
Des weiteren auch mittelfristig Beispiele zur Verfügung zu stellen, die man gegen DIE DB testen kann, die man gerade hat und nicht diejenige, die der Ersteller eines Beispieles nutzt.
(Speziell auf eine bestimmte DB zugeschnittene Beispiele mal ausgenommen)

Und da bin ich wieder bei den Datenmodulen für Benutzer der grafischen Umgebung.
Da brauche ich dann wohl für ZEOS und SQLDB je ein Datenmodul. Und dann wieder den Code der mehrfach ist grrrr

[charlytango]

@af0815 Ich nehme an dass deine Beispiele nicht in einem grafischen Datenmodul klappen?
(also Datenmodul in der GUI erzeugen und Komponenten drauf kleben)

Oder bin ich da auch auf dem Holzweg?

[af0815]

@af0815 Ich nehme an dass deine Beispiele nicht in einem grafischen Datenmodul klappen?
(also Datenmodul in der GUI erzeugen und Komponenten drauf kleben)

Oder bin ich da auch auf dem Holzweg?

Klares Jaein. Entweder doppelt draufklatschen und im Programm dann richtig zuweisen. Oder gleich dynamisch erstellen, zumindest die Connection. Grafische Komponenten kann man nicht bedingt kompilieren (leider). Deswegen von mir auch der Kniff, das ganze auf eine 'virtuelle' nicht grafische Komponente zu mappen und ganz auf das hinaufklatschen von GUI-Connections und GUI-Queries zu verzichten.

Vielleicht geht das bedingte Einbinden der lfm mit viel Buchweh, ist aber keine sichere Lösung IMHO. Ich würde die Komponenten so wie im Beispiel zur Laufzeit erzeugen und die ganzen Aufrufe in einem Datenmodul zusammenfassen. Dann hat man nur einen 'Point of Failure'.

Das ganze ist mir im Endeffekt auf den Sa... gegangen, deswegen habe ich mich in weiteren Projekten entweder für SQLDB oder ZEOS entschieden und bei der Linie bin ich geblieben. Und bei Android sieht die Sache noch besch...eidener aus.

[charlytango]

Deswegen von mir auch der Kniff, das ganze auf eine 'virtuelle' nicht grafische Komponente zu mappen und ganz auf das hinaufklatschen von GUI-Connections und GUI-Queries zu verzichten.

Dann hab ich den Trick ja doch nicht übersehen

Aber damit ist das ganze Konzept, zur Designzeit irgend etwas einbinden oder gar anzeigen zu wollen beim Teufel.

Ich kann deinen Frust irgendwie nachvollziehen und da bleibt mir nur die Entscheidung zwischen Pest und Cholera

[af0815]

Es ist kein Frust, ich habe sowieso vorher schon entschieden nicht direkt mit RAD im DB Bereich zu arbeiten.