Wo häufig benötigte Daten speichern

[Aviator]

Hallo Community,

wie im Titel schon minimalistisch "angesprochen", würde ich gerne wissen, wo man generell Daten ablegt, die während dem Programmablauf immer wieder benötigt werden.
Beispielsweise brauche ich den Benutzernamen des Benutzers der gerade am Programm angemeldet ist immer wieder. Zusätzlich noch die Berechtigungen, die der User hat und dann noch die Benutzereinstellungen, die sich der User wie der Name schon sagt, selbst definiert hat.

Meine Frage also nochmal konkretisiert: Wo werden solche Daten sinnvollerweise im Programm (wenn überhaupt dort) "zwischengespeichert", damit ich immer direkten Zugriff darauf habe? Die Daten in einer Datenbank, Ini oder in der Registry zu speichern und immer dann wenn diese gebraucht werden sie von dort zu lesen, braucht m. E. immer sehr viel Zeit. Ist es vielleicht sinnvoll, sich ?globale? Records/Variablen/Properties zu setzen und diese immer wieder abzurufen?

Ich hoffe, dass ich meine Frage verständlich gestellt habe. Sollte es noch weitere Fragen dazu geben, bin ich gerne offen dafür, diese zu beantworten, sofern ich sie beantworten kann.

Schonmal im Voraus ein Danke für dich möglichen Antworten.

PS.: Die Google und DP-Suche hat mich bei diesem Problem leider nicht weitergebracht, da ich sicherlich auch nicht die passenden Begriffe gefunden habe, um danach zu suchen.

[Furtbichler]

Wie wäre es 'oldfashioned' mit einem Datenmodul. Das war vor 30 Jahren, als die Dinger erfunden wurden, state-of-the-art. Ein Datenmodul ist der zentrale Container für Daten aller Art, damit sie nicht über Parameter hin und her transportiert werden müssen. Heute macht man das mit OOD, aber da muss man sich erst einmal einarbeiten.

Ein TDataModule ist einfacher zu verstehen. Ist praktisch wie die riesige Pinnwand im Büro.

[Aviator]

Wenn ich es richtig verstanden habe, dann ist OOD ein Pattern, welches ähnlich wie MVVM in WPF arbeitet. Ich habe mich während der Entwicklung einer WPF Anwendung damit beschäftigt, bin jedoch nicht 100%ig daraus schlau geworden, konnte es schlussendlich dann auch nur näherungsweise umsetzen.

Zur Sache mit dem TDataModule. Diese Klasse muss ja auch irgendwo in meinem Programm erzeugt werden, um die Daten dort hinein zu speichern. An welcher Stelle jedoch wird diese Klasse jedoch erzeugt, damit ich auch auf diese von überall Zugriff habe? Oder habe ich dort etwas Grundlegendes falsch verstanden bzw. wie gebt/gibst ihr/du Informationen an eine andere Klasse/Unit weiter, wenn ihr beispielsweise eine neue Form mit

Delphi-Quellcode:

Form2.Show

sichtbar macht bzw. öffnet? Genau zu diesem Zeitpunkt müssen ja die Daten im anderen "Fenster" verfügbar sein, damit ich damit arbeiten kann.

[Bernhard Geyer]

Für so einen Container würde sich das Singleton-Pattern anbieten.

[Der schöne Günther]

Das TDataModule ist für mich auch noch ziemlich neu, aber wenn ich es richtig sehe, dann ist es doch ein Quasi-Singleton für das die IDE (wie für Formulare auch) automatisch einen

Delphi-Quellcode:

Application.CreateForm(..)

-Aufruf in die DPR bastelt. Inklusive globaler Variable für den Zugriff. Standardmäßig. Muss man ja nicht so behalten.

Wenn du kein lazy-loading oder sonstwas noch reinbasteln willst wäre ich doch fürs erste damit zufrieden, in der DPR die Erstellung des TDataModules ganz nach oben zu schieben und gut ist?


PS: Wahrscheinlich ist es schon spät, aber was ist jetzt mit OOD gemeint? Mir fällt nichts ein, allerdings habe ich mit der WPF auch nichts am Hut. Und großer Gott, Google-Bildersuche nach "OOD", GROßER GOTT!

[Sir Rufo]

Ganz simpel und einfach

Delphi-Quellcode:

unit Layer_App;

interface

type
  IAppLayer = interface
    [{GUID}]
    // Zugriff auf Pfade, die die Anwendung benutzt
    function Paths : TAppPaths;
    // Der aktuelle User
    function User : TUser;
    // Die Datenzugriffsschicht/-en
    function Data : TDataLayer;
  end;

function AppLayer : IAppLayer;

implementation

type
  TAppLayer = class( TInterfacedObject, IAppLayer )
  public
    function Paths : TAppPaths;
    function User : TUser;
    function Data : TDataLayer;
  end;

var
  _AppLayer : IAppLayer;

function AppLayer : IAppLayer;
begin
  if not Assigned( _AppLayer ) then
    _AppLayer := TAppLayer.Create;
  Result := _AppLayer;
end;

end.

Jetzt nur noch überall die Unit einbinden und fröhlich mit dem AppLayer arbeiten.

Genauso denkbar ist natürlich auch dieses hier

Delphi-Quellcode:

unit Layer_App;

interface 

type
  AppLayer = class
  public
    // Zugriff auf Pfade, die die Anwendung benutzt
    class function Paths : TAppPaths;
    // Der aktuelle User
    class function User : TUser;
    // Die Datenzugriffsschicht/-en
    class function Data : TDataLayer;
  end;

implementation

// jo hier noch implementieren

end.

Der Zugriff ist bei beiden Varianten absolut gleich

Delphi-Quellcode:

AppLayer.User.*

.
Ist dann also Geschmacksache mit der Ausnahme, dass bei generischen Methoden, die Interfaces nicht mitspielen.

Delphi-Quellcode:

IFoo = interface
  procedure DoWith<T>( Value : T ); // geht nicht
end;

TFoo = class
public
  class procedure DoWith<T>( Value : T ); // geht
end;

[Sir Rufo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1239365)

PS: Wahrscheinlich ist es schon spät, aber was ist jetzt mit OOD gemeint? Mir fällt nichts ein, allerdings habe ich mit der WPF auch nichts am Hut. Und großer Gott, Google-Bildersuche nach "OOD", GROßER GOTT!

Objekt Orientiertes Design ;)

[Aviator]

Das mit dem Singleton-Pattern klingt ja schonmal ganz gut. Danke für den Hinweis. Mit Interfaces habe ich bisher nur in Verbindung mit einem VirtualTree View zum Editieren von Nodes gearbeitet, sonst jedoch noch nicht. Von daher ist das was Sir Rufo geschrieben hat noch nicht 100% verständlich für mich. Ich muss dazu sagen, dass ich weder in der Schule noch in einem Studium oder in einer Ausbildung das Programmieren gelernt habe. Alles was ich kann, habe ich mir über die Jahre selbst beigebracht. Im Prinzip "Learning By Doing". Ich entwickele zwar des öfteren kleinere oder auch mal größere Anwendungen für die Firma in der ich arbeite, allerdings eben nur mit dem Wissen, das ich habe. Ich bin offen für alle Neuerungen, die mir das Programmieren erleichtern, wenn ich es einmal verstanden habe. Zur Zeit bin ich an einem größeren Projekt, weshalb ich hier um Rat frage, wie man global verfügbare Daten im Programm abspeichert, um immer wieder darauf zuzugreifen.

Die Programmberechtigungen speichere ich zur Zeit während das Programm läuft in einem Set ab, was wirklich sehr gut funktioniert. Gespeichert werden die Rechte dann als Binärzahl in einer Datenbank. Dieses Set könnte ich dann wenn ich es richtig verstanden habe, ebenfalls in diesem DataContainer ablegen. Wenn ich hier falsch liegen sollte, dann korrigier mich bitte jemand.

Vielleicht könnte auch jemand ein kleines Beispiel machen, wie man denn einen TDataContainer aus mehreren Klassen benutzen kann. Mit einem kleinen Beispiel fällt mir das Verstehen immer um einiges leichter, als immer nur theoretisch darüber zu schreiben bzw. nachzudenken.

Danke für die Mühe, wenn sich jemand diese Arbeit für mich macht. :thumb:

[Sir Rufo]

Die Berechtigung ist doch für den User, also merk dir das im User-Bereich

Delphi-Quellcode:

AppLayer.User

.
Der DataLayer ist für das Speichern und Laden verantwortlich. Dort wird dann auch entschieden, in welchen Topf gespeichert werden muss (welche Datenbank, welche Tabelle oder auch Datei, Registry oder wo auch immer).

Der Anwendung ist es egal woher die Daten kommen und wohin die gehen, der DataLayer muss es richten, das ist sein Job ;)

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1239368)

Ganz simpel und einfach

Gibt's da irgendwo noch ein paar Beispiele und Erläuterungen zu ?
(nach Möglichkeit ohne irgendwelche Modevokabeln)
Sieht interessant aus!

Gruß
K-H