Die Sache mit dem Listenproperty

[sakura]

Hi

Zitat von Delbor:

Es gibt in dieser Anwendung nur den einen Thread. Einen zweiten wird es wohl nicht geben. Denn trotz dem Einsatz von MySQL handelt es sich um eine Desktopanwendung. Und auch wenn es mehrere Threads neben dem Haupttread geben sollte. müssten diese in einer Criticalsection auf den Speicher zugreifen. Dazu käme wohl noch der Zugriff auf ein Objekt...

Eine gute Richtlinie ist es aber immer so zu entwickeln, als könnten solche Informationen an mehreren Stellen gleichzeitig gebraucht werden, das macht spätere Erweiterungen leichter. Auch bei Desktopanwendungen ist Multi-Threading schon lange keine Ausnahme mehr.

Zitat von Delbor:

Das Ergebnis dient dazu, die Tabellen der DB anzuzeigen. Das Property soll die Tabellen nach oben zur Verfügung stellen; die Gui muss nur daruf zugreifen. Ich weiss: dazu gibt es bei Firedac die Connection-Komponente.

Warum dann lädst Du die Liste der Tabellen mit jeder Anfrage, anstatt nur einmal. Ändern werden sich die Tabellen ja wohl kaum...?

Zum Thema Rückgabewert, wenn irgendein Aufrufer die Liste zerstört (Destroy, Free), dann wird es Zugriffsverletzungen geben, entweder später oder beim Beenden. Deswegen die Frage, warum nicht ein Array zurück geben?

......

[TBx]

Zitat von sakura:

Hi
Zum Thema Rückgabewert, wenn irgendein Aufrufer die Liste zerstört (Destroy, Free), dann wird es Zugriffsverletzungen geben, entweder später oder beim Beenden. Deswegen die Frage, warum nicht ein Array zurück geben?
......

[Ironie]oooch, das wurde doch schon abgebacken:

Zitat von DeddyH:

Naja, wer das tut, ist ja selber Schuld. Oder gibst Du z.B. TComboBox.Items auch frei?

[/Ironie]

[sakura]

Zitat von TBx:

[Ironie]oooch, das wurde doch schon abgebacken:

Zitat von DeddyH:

Naja, wer das tut, ist ja selber Schuld. Oder gibst Du z.B. TComboBox.Items auch frei?

[/Ironie]

Ich weiß, und auch das finde ich persönlich eher unschön, ist aber den alten Zeiten zu danken und lässt sich heute auch nicht mehr ändern...

......

[TBx]

@sakura:

[DeddyH]

Damit es Ruhe hat:

Delphi-Quellcode:

type
  TDingens = class
  private
    FTablenames: TStringList;
    function GetTablenames(Index: integer): string;
    function GetTablenameCount: integer;
  public
    constructor Create;
    destructor Destroy; override;
    property TablenameCount: integer read GetTablenameCount;
    property Tablenames[Index: integer]: string read GetTablenames;
  end;

...

constructor TDingens.Create;
begin
  FTablenames := TStringList.Create;
  FillTablenamesFormSomewhere(FTablenames);
end;

destructor TDingens.Destroy;
begin
  FTablenames.Free;
  inherited;
end;


function TDingens.GetTablenames(Index: integer): string;
begin
  Result := FTablenames[Index];
end;

function GetTablenameCount: integer;
begin
  Result := FTablenames.Count;
end;

Damit kann man dann durch die Liste iterieren, hat aber keinen direkten Zugriff darauf.

[sakura]

Zitat von DeddyH:

Damit es Ruhe hat

Ach komm, biete doch noch einen Listen-Enumerator an

......

[DeddyH]

*Pff*

[Delbor]

Hi Sakura

Genaugenommen wird die Anfrage bei jedem lesezugriff auf das Property ausgeführt. Die Alternative wäre, die SQL-Anfrage ausserhalb des Datenmoduls dann da ausführen, wo ich sie brauche. Zum Bleistift in einem PageControl zur Anzeige von Metadaten auf der Mainform. Damit hätte ich dann eine weitere Prozedur in der Mainform, die es allenfalls zu ändern (und erstmal zu finden) gibt. Und wenn ich mehrere Informationen, für deren Beschaffung das Datenmodul zuständig ist, von ausserhalb abfrage, habe ich auch ausserhalb eine entsprechende Anzahl Methoden, die mir diese Infos beschaffen - und sollte sich irgendwas ändern, zum Bleistift an der Datenbank/Tabellenstruktur, darf ich alll diese Methoden ausserhalb des Datenmoduls da ändern, wo ich sie angelegt habe. Das muss nicht zwingend die Mainform sein, das kann eine andere Form oder ein Frame - im schlimmsten Fall pro Prozedure/SQL-Statement - sein. Wenn ich das im alles im Datenmodul habe, muss ichs auch nur da ändern.
Auch wenn ich Methoden von ausserhalb nur aufrufe - wenn sich die Art des Aufrufens ändert (Parameter können sich ändern etc), darf ich alle diese Aufrufe an verschiedenen Stellen des Programmes ändern.

Eine gute Richtlinie ist es aber immer so zu entwickeln, als könnten solche Informationen an mehreren Stellen gleichzeitig gebraucht werden, das macht spätere Erweiterungen leichter. Auch bei Desktopanwendungen ist Multi-Threading schon lange keine Ausnahme mehr.

Ja eben: genau deswegen ist es besser, das Datenmodul stellt die Infos als Propery bereit. Ansonsten müsste jede dieser Stellen das SQL-Statement aufrufen. Das Statement selbst, bzw. desse Ausführung, dürfte vo der Performance her kaum ins Gewicht fallen.
Und nochmals: sollte ich mit einem andern als dem Hauptthread auf das Property zugreifen, dann nur in einer Criticalsection.

Anders sieht es allerdings aus, wenn ich meine BilderDatenbank abfrage: Hier werden die Ergebnisse pro Datensatz in eine Klasse geschrieben (und diese in eine Objectliste gepackt), so dass die Abfrage selbst im Normalfall nur einmal durchgeführt werden muss.

Gruss
Delbor