Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Klasse für Datenbankoperation. Richtiger weg? (https://www.delphipraxis.net/47246-klasse-fuer-datenbankoperation-richtiger-weg.html)

Sharky 8. Jun 2005 11:07


Klasse für Datenbankoperation. Richtiger weg?
 
Liste der Anhänge anzeigen (Anzahl: 1)
Hai,

zur Zeit tippe ich aus Spass eine kleine Buchverwaltung.
Um eine möglichst klare Trennung zwichen der GUI und den "Tabellenoperationen" zu haben dachte ich mir diese jeweils in eine kleine Klasse zu packen.

Als Beispiel hänge ich mal die Unit für die Autoren an. Ist dies der richtige Ansatz?

P.S.: In diesem Fall ist eine AbsoluteDatabase verwendet. Aber das sollte ja egal sein.

Für Anregungen bin ich immer dankbar.

r2c2 8. Jun 2005 11:45

Re: Klasse für Datenbankoperation. Richtiger weg?
 
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Shary,
ich kann zwar nicht behaupten, dass ich besonders viel Programmiererfahrung hab, aber ich bin auch gerade dabei sone Art Bibliotheksverwaltung zu schreiben. Vielleicht interessieren dich auch meine Ansätze(ob du damit was anfangen kannst steht wahrscheinlich au nem anderen Blatt :zwinker: ).

Zur Info:
- Ich benutze MySQL und MySQLdirect
- Ich hab eine Klasse TBib, die alle Objekte instanziert und wieder freigibt
- Eine globale Variable Bib: TBib;
- Alle anderen Objekte greifen über diese globale Variable auf die anderen zu.(ja ich weiß: schön is was anders, aber so spar ich mir die TypeCasts)

mfg

Christian

barf00s 8. Jun 2005 11:57

Re: Klasse für Datenbankoperation. Richtiger weg?
 
hmm, das bisschen code sah an und für sich gut aus :)
WENN
- man über das mischen von englisch/deutsch hinweg sieht
- und dem string parameter im constructor nochn const verpasst

:)

naja und das ladeautor - da wird ja JEDESMAL erst eine instanz von dem query dingen erstellt - kA inwiefern das performant bleibt/ist für mehrerere ladeautor-vorgänge :)

Sharky 8. Jun 2005 12:23

Re: Klasse für Datenbankoperation. Richtiger weg?
 
Zitat:

Zitat von barf00s
... kA inwiefern das performant bleibt/ist für mehrerere ladeautor-vorgänge :)

Wenn es darum geht alle Autoren zu laden werde ich dafür natürlich eine eigene Methode in der Klasse haben. Mir ging es ja um das Prizip das ich anwenden möchte.

P.S.: Das mit dem Englisch/Deutsch ist halt immer so eine Sache. Wähle ich alle "Namen" in Englisch oder in Deutsch?
Aber auch das sollte jetzt nicht die Frage in diesem Thread sein :-D

franktron 8. Jun 2005 12:47

Re: Klasse für Datenbankoperation. Richtiger weg?
 
Also das sieht doch ganz gut aus nur ob das auch schnell ist ist die Frage.

[EDIT] Damit das ein bischen schneller geht würd ich TABSQuery.Create(nil) beim Constructor erstellne und global Deklarieren [/EDIT]

Sharky 8. Jun 2005 13:05

Re: Klasse für Datenbankoperation. Richtiger weg?
 
Liste der Anhänge anzeigen (Anzahl: 1)
Hai franktron,

ich habe jetzt mal zum Test diesen Code benutzt um einen neuen Autor anzulegen:
Delphi-Quellcode:
procedure TAutor.AC_SpeichernExecute(Sender: TObject);
var
  Autor: TAutorClass;
  Daten: TAutorDaten;
  start: cardinal;
  ende: cardinal;
begin
  start := GetTickCount;
  Autor := TAutorClass.Create('data');
  try
    Daten.ID   := -1;
    Daten.Name := E_Name.Text;
    Daten.Memo := Memo1.Text;
    Autor.Daten := Daten;
    Autor.SpeicherAutor;
  finally
    Autor.Free;
  end;
  ende := GetTickCount;
  ShowMessageFmt('Es dauerte %d ms', [ende - start]);
end;
Alles in allem hat es 62ms - 100ms gedauert. Ich denke das ist okay. Andererseits kann ich das Query auch im Constructor der Klasse erzeugen. Er wird ja eh benötigt.

Genau darum habe ich ja diesen Thread gestartet :stupid:

Edit
Ich habe das Query jetzt mal im Constructor erzeugt. Das macht es auch einfacher das ganze auf eine andere DB zu portieren.


Alle Zeitangaben in WEZ +1. Es ist jetzt 08:02 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz