[XE5]: Nutzung des Datenmoduls

[Kralle]

Moin,

Zitat von Sir Rufo:

Als globalen Speicher immer ein Singleton (Klasse oder Interface) benutzen.

Warum:

• Zugriff kann threadsicher gemacht werden
• Auf Änderungen kann reagiert werden (im Setter)
• Abhängigkeiten zwischen den Variablen können automatisiert werden
• Speichern und Laden kann direkt in die Klasse integriert werden
• ...

Hört sich kompliziert an, ist es aber nicht.

Zu mindest die "class"-Lösung kann ich was das Erstellen betrifft nachvollziehen.
Und packst Du das in eine "normale" Unit oder in ein Datenmodul?
Und wie greifst Du aus einer anderen Unit darauf zu?


Gruß HEiko

[Sir Rufo]

Bei der class Variante heißt die Klasse Global = class und bei der interface Variante gibt es eine function Global : IGlobal; .

Beide Varianten sind in der Benutzung identisch

Delphi-Quellcode:

unit Somewhere;

interface

procedure foo;

implementation

uses
  GlobalStore;

procedure foo;
begin
  if Global.UserID = 10 then
    ...
end;

[DeddyH]

Auch zu einem Datenmodul gehört eine Unit, das hat mit globalen Variablen nur sehr wenig zu tun. http://docwiki.embarcadero.com/Libra...es.TDataModule:

Zitat:

TDataModule zentralisiert die Behandlung von nicht-visuellen Komponenten in einer Anwendung.

Mit einem TDataModule-Objekt können Sie in einer Anwendung einen Ort für die zentralisierte Behandlung von nicht-visuellen Komponenten bereitstellen. In der Regel handelt es sich dabei um Datenzugriffskomponenten, wie TSQLDataSet und TSQLConnection. Datenmodule sind nicht auf Datenzugriffskomponenten beschränkt, sie können auch andere nicht-visuelle Komponenten, wie TTimer, TOpenDialog oder TImageList, enthalten.

Man nimmt also ein Datenmodul, klatscht da seine nicht-visuellen Komponenten drauf, stellt sie zur Designtime ein und kann zentral darauf zugreifen.

[TiGü]

Sir Rufo hat dir schon eine vollständige Lösung für dein Problem gezeigt.

Um sein letztes Beispiel nochmal zu verdeutlichen:

Delphi-Quellcode:

unit SomeOtherUnitFromYourProject;

interface

procedure BlaBla;

implementation

uses
  GlobalStore; //ja, das ist die gleiche Unit

procedure BlaBla;
begin
  GlobalStore.Global.UserID := 10;

  if GlobalStore.Global.UserName = 'Kralle' then
  begin
    Writeln('Brauche eigentlich für mein Problem kein Datenmodul!');
  end;
end;

[Sir Rufo]

Und wenn man den GlobalStore mit ein wenig Logik versieht, dann wird beim Setzen von Global.UserId auch schon passend dazu Global.UserRoleID und Global.Username gesetzt.

Oder das passiert auch beim Setzen des Usernamen (UserID, UserRoleID).

UserRoleID könnte zudem auch ReadOnly sein

Oder alle Felder sind ReadOnly und es gibt noch eine Login-Methode die dann diese Felder setzt.
Oder ...

[sx2008]

Folgende zwei Codefragmente sind äquivalent:

Delphi-Quellcode:

type
  Global = class
  private
    class var FUserID : Integer;
    class var FUserRoleID : Integer;
    class var FUsername : string;
    class procedure SetUserID( const Value : Integer );
    class procedure SetUsername( const Value : string ); static;
    class procedure SetUserRoleID( const Value : Integer ); static;
  public
    class property UserID : Integer read FUserID write SetUserID;
    class property UserRoleID : Integer read FUserRoleID write SetUserRoleID;
    class property Username : string read FUsername write SetUsername;
  end;

Das ist im Prinzip nix anderes wie 3 globale Variablen

Delphi-Quellcode:

var
  UserID : Integer;
  UserRoleID : Integer;
  Username : string;

Ob man jetzt noch ein Interface darüberlegt oder den Username automatisch mit der UserID setzt ändert nichts daran dass hier ein "Sack voller globaler Variablen" vorliegt.
Ich habe dazu ein Tutorial geschrieben das für den Einen oder Anderen interessant sein könnte.

[himitsu]

Der Vorteil es nicht nur als viele globale Variablen zu machen, ist der, daß man sich später problemlos da überall reinhängen kann, ohne daß am Aufrufenden Code etwas geändert werden muß.

Das reicht schon vollkommen.

Delphi-Quellcode:

type
  Global = class abstract
  private class var 
    FUserID : Integer;
    FUserRoleID : Integer;
    FUsername : string;
  public
    class property UserID : Integer read FUserID write FUserID;
    class property UserRoleID : Integer read FUserRoleID write FUserRoleID;
    class property Username : string read FUsername write FUsername;
  end;

Getter und Setter läßt sich nachträglich einfügen und schon kann man Code für eine Werte-Kontrolle der Felder integrieren, oder ein Logging oder oder oder...

Und viel mehr Aufwand ist es auch nicht.

Delphi-Quellcode:

type
  Global = class abstract
    class property UserID : Integer;
    class property UserRoleID : Integer;
    class property Username : string;
  end;

Nun nur noch Strg+Alt+C (Klassenvervollständigung) und fertig isses.


OK, abgesehn von dem BUG, welcher hier grade auftritt.
Denn so sollte das Ergebnis der Klassenvervollständigung wirklich nicht aussehn.

Delphi-Quellcode:

  Global = class abstract
    class property UserID : Integer read FUserID write SetUserID;
    class property UserRoleID : Integer read FUserRoleID write SetUserRoleID;
    class property Username : string read FUsername write SetUsername;
  private
    FUserID: Integer;
  private
    class var FUserRoleID: Integer;
  private
    class var FUsername: string;
  private
  private
  private
    procedure SetUserID(const Value: Integer);
    class procedure SetUsername(const Value: string); static;
    class procedure SetUserRoleID(const Value: Integer); static;
  end;

[Sir Rufo]

Zitat von sx2008:

Folgende zwei Codefragmente sind äquivalent:
...
Das ist im Prinzip nix anderes wie 3 globale Variablen
...
Ob man jetzt noch ein Interface darüberlegt oder den Username automatisch mit der UserID setzt ändert nichts daran dass hier ein "Sack voller globaler Variablen" vorliegt.

Ja richtig, nur mit dem kleinen aber feinen Unterschied, dass globale Variablen unkontrollierbar und damit/darum böse sind.
In einer Klasse/Interface werden die aber kontrollierbar.