Man darf nicht alles in eine Klasse oder eine
Unit packen.
Das führt zu einem Design, das schlecht wiederverwendbar ist.
Es gibt z.B. eine Klasse TUserPermissions und diese benötigt einen Zugriff auf die Benutzertabelle.
Die Komponente für die Tabelle liegt aber auf dem Hauptformular.
Würde man das Hauptformular in die
Unit einbinden, wäre das natürlich ganz schlecht.
Dann muss die Klasse TUserPermissions eben von Aussen mit geteilt bekommen aus welchem Dataset die Zugriffsrechte auszulesen sind.
Das sieht dann ungefähr so aus:
Delphi-Quellcode:
TUserPermissions = class(..)
....
public
...
function WorkerExists(const _name: string): boolean;
property UserDataset:TDataset read FUserDataset write SetUserDataset;
end;
function TUserPermissions.WorkerExists(const _name: string): boolean;
begin
{
Ja, Locate ist nicht besonders schnell.
Aber bei Datasets, die nicht mehr als 200 Datensätze haben reicht das vollkommen aus
Es gibt Techniken, mit dem man auch dieses Problem elegant und objektorientiert umschiffen kann
(einfach fragen)
}
Result := FUserDataSet.Locate('UserName', _name, ...);
end;
Wichtig ist, dass das Property vom Typ TDataset ist (nicht TTable, TAdoQuery, TZeosQuery oder ähnliches).
Vorteil: die Klasse für die Zugriffsrechte bleibt unverändert auch wenn man z.B. von
BDE-Komponenten zur Zeos-Komponenten wechselt.
Jede Klasse und
Unit hat ihre Verantwortlichkeiten.
Hautpformular:
* erstellt Datenbankverbindung
* erzeugt ein Objekt der Klasse TUserPermissions
* stellt Datasets für die Klasse TUserPermissions bereit
sollten die Aufgaben für das Hautpformular zu viel werden, sollte man ein Datenmodul einführen.
Klasse TUserPermissions:
* bekommt sein Dataset von Aussen mitgeteilt
* weiss nur, wie die Felder heisen und kann damit arbeiten
* hat aber keine Anhnung auf welcher
DB und in welcher Tabelle die Daten liegen