Best practice: Benutzerverwaltung mit Datenbankanbindung

[Morphie]

Danke für deine Antwort.

Wie die Logik dahinter funktioniert war mir natürlich klar, das ist wie gesagt in C# umgesetzt.
Mir ging es eher um den technischen Aspekt (DataLayer, Binding) und wie man es in Delphi richtig macht.

Ich habe wie gesagt bisher immer Recordsetorientiert in Delphi programmiert.
In .NET programmiere ich allerdings vollkommen Objektorientiert.

Da hier aber oft von ORMs für Delphi gesprochen wird, wollte ich wissen, ob das wirklich praxistauglich ist, oder man doch lieber bei der klassischen Recordsetprogrammierung bleiben sollte...

Wenn man seine Datenbankobjekte dann in Delphi-Klassen kapseln würde, wie bindet man diese dann sauber an die Oberfläche (z.B. an Listen oder Grids)? Bzw. wie trennt man hier die Oberfläche sauber von den Daten?


OT: Es geht mir oft so, dass ich eine Frage stelle, aber leider nicht richtig verstanden werde...
Wenn ich meine Fragen also etwas unverständlich schreibe, dann bitte ich das zu entschuldigen

[DataCool]

Hi Morphie,

dann schau Dir doch mal das D-ORM an:
https://code.google.com/p/delphi-orm/

Scheinbar schon produktiv durch den Author selbst in einigen großen Projekten verwendet.
Ich bin gerade selber am überlegen, ob ich es mal wagen soll das einzusetzen.

Ansonsten versuche ich immer die DB-Struktur in Objekten abzubilden,
habe mir ein kleines Tool geschrieben was anhand der DB-Struktur Quellcode generiert(Objekte + Listen(Objectlist/Generic-TObjectList)).
Außerdem verwende ich die DevExpress-Komponenten, wo zur Darstellung meistens wunderschön ein cxGrid verwendet werden kann.
Für dieses kann je nach Daten eine eigene Abteiltung von TcxCustomDataSource erstellt werden,
die dann in der Gui wie jeder anderer DataSource dem Grid zugewiesen werden kann.

Hoffe das hilft Dir weiter,

Greetz Data

[Morphie]

Hi Na das geht doch schon mal in die richtige Richtung

Ja, an sowas habe ich auch schon gedacht... Also einen Codegenerator zu schreiben, der mir meine Datenbankobjekte in Delphi-Objekte abbildet. Viel anders macht es das EntityFramework bei DatabaseFirst ja auch nicht...

Es gibt dann noch einen DataContext, der das Abrufen der Daten übernimmt (z.B. function GetCustomersByName(AName: String): List<TCustomer>; ) und Änderungen verfolgt und diese bei procedure SaveChanges; wieder zurück in die Datenbank schreibt...

Komplizierter wird es dann bei Relationen (Master / Details)...

Ich kenne mich mit den DevExpress-Controls nicht so gut aus... Wie sieht so eine Implementierung einer TcxCustomDataSource-Ableitung aus?

[DataCool]

Hi Morphie,

eigentlich sieht so ein abgeleiteter DataSource recht simpel aus:

Delphi-Quellcode:

unit uMitarbeiterDS;

{$I cxVer.inc}

interface

uses
  Variants, Classes,
  cxCustomData, cxGridCustomTableView,
  uMitarbeiter;

const
  IndexOfID = 0;
  IndexOfPersNr = 1;
  IndexOfNachName = 2;
  IndexOfVorname = 3;
  IndexOfUpdated_at = 4;
  IndexOfCreated_at = 5;

type


  TDemoMitarbeiterDataSource = class(TcxCustomDataSource)
  private
    FMaList: TMitarbeiterList;
    FModified: boolean;
  protected
    function GetRecordCount: Integer; override;
    function GetValue(ARecordHandle: TcxDataRecordHandle; AItemHandle: TcxDataItemHandle): Variant; override;
    function AppendRecord: TcxDataRecordHandle; override;
    procedure DeleteRecord(ARecordHandle: TcxDataRecordHandle); override;
    function InsertRecord(ARecordHandle: TcxDataRecordHandle): TcxDataRecordHandle; override;
    procedure SetValue(ARecordHandle: TcxDataRecordHandle;  AItemHandle: TcxDataItemHandle; const AValue: Variant); override;
  public
    constructor Create(AMaList: TMitarbeiterList);
    property Modified: boolean read FModified;
    property MitarbeiterList : TMitarbeiterList read FMaList;

    function GetDataObjectByHandle(ARecordHandle: TcxDataRecordHandle): TMitarbeiter;
  end;


implementation

{ TCustomDataSource }

constructor TDemoMitarbeiterDataSource.Create(AMaList: TMitarbeiterList);
begin
  inherited Create;
  FMaList := AMaList;
end;

function TDemoMitarbeiterDataSource.AppendRecord: TcxDataRecordHandle;
var
  aMa: TMitarbeiter;
begin
  aMa := TMitarbeiter.Create(FMaList.Connection);
  Result := TcxDataRecordHandle(FMaList.Add(aMa));
  DataChanged;
  if not Modified then
    FModified := True;
end;

procedure TDemoMitarbeiterDataSource.DeleteRecord(ARecordHandle: TcxDataRecordHandle);
begin
  FMaList.Delete(Integer(ARecordHandle));
  DataChanged;
  if not Modified then
    FModified := True;
end;

function TDemoMitarbeiterDataSource.GetDataObjectByHandle(
  ARecordHandle: TcxDataRecordHandle): TMitarbeiter;
begin
  try
    Result := FMaList[Integer(ARecordHandle)];
  except
    result := nil;
  end;
end;

function TDemoMitarbeiterDataSource.GetRecordCount: Integer;
begin
  Result := FMaList.Count;
end;

function TDemoMitarbeiterDataSource.GetValue(ARecordHandle: TcxDataRecordHandle;
  AItemHandle: TcxDataItemHandle): Variant;
var
  AColumnId: Integer;
  aMa: TMitarbeiter;
begin
  aMa := FMaList[Integer(ARecordHandle)];
  AColumnId := GetDefaultItemID(Integer(AItemHandle));
  case AColumnId of
    IndexOfID : Result := aMa.ID;
    IndexOfPersNr     : Result := aMa.PersNr;
    IndexOfNachName   : Result := aMa.Nachname;
    IndexOfVorname    : Result := aMa.Vorname;
    IndexOfUpdated_at : Result := aMa.Updated_at;
    IndexOfCreated_at : Result := aMa.Created_at;
  end;
end;

function TDemoMitarbeiterDataSource.InsertRecord(
  ARecordHandle: TcxDataRecordHandle): TcxDataRecordHandle;
var
  aMa: TMitarbeiter;
begin
  aMa := TMitarbeiter.Create;
  FMaList.Insert(Integer(ARecordHandle), aMa);
  Result := TcxDataRecordHandle(ARecordHandle);
  DataChanged;
  if not Modified then
    FModified := True;
end;

procedure TDemoMitarbeiterDataSource.SetValue(ARecordHandle: TcxDataRecordHandle;
  AItemHandle: TcxDataItemHandle; const AValue: Variant);
var
 aMa: TMitarbeiter;
 AColumnId: Integer;
begin
  AColumnId := GetDefaultItemID(Integer(AItemHandle));
  aMa := FMaList[Integer(ARecordHandle)];
  case AColumnId of
    IndexOfID :
      begin
        if VarIsNull(AValue) then
          aMa.ID := 0
        else
          aMa.ID := AValue;
      end;
    IndexOfPersNr     : aMa.PersNr    := VarToStr(AValue) ;
    IndexOfNachName   : aMa.Nachname  := VarToStr(AValue) ;
    IndexOfVorname    : aMa.Vorname   := VarToStr(AValue) ;
    IndexOfUpdated_at :
      begin
        // Read-Only
        (*
        if VarIsNull(AValue) then
          aMa.Updated_at := 0
        else
          aMa.Updated_at := VarToDateTime(AValue);
        *)
      end;
    IndexOfCreated_at :
      begin
        // Read-Only
      end;
  end;
  if not Modified then
    FModified := True;
end;

end.

Unterm Strich musst Du "nur" definieren welche Spalten/Fields Dein CustomDataset bereitstellt und dafür dann GetValue & SetValue schreiben.

Greetz Data

[Morphie]

Ach was wäre die Welt langweilig, wenn Embarcadero für solche Zwecke mal ein gescheites Framework / gescheite Assistenten mitliefern würde...
Jetzt habe ich jedenfalls erst mal ne Menge Lesestoff, mit dem ich mich beschäftigen kann

Danke DataCool

Zitat von mjustin:

Warum nicht einfach Benutzer -> Rolle (eine oder mehrere) -> Rechte? Dann kann man immer noch besondere Benutzer definieren, die mehr Rechte haben (Admin). Ist natürlioch Geschmackssache, ob man neben Gruppen auch Benutzer einzeln verwalten möchte.

Bei mir sieht es sogar noch ein wenig anders aus

Benutzer
Gruppe
Mandant

Ein Benutzer kann zugriff auf mehrere Mandanten haben
Eine Gruppe kann ebenfalls zugriff auf mehrere Mandanten haben
Ein Benutzer kann in mehreren Gruppen sein

Der Gruppe werden pro Mandant eigene Rechte gegeben
Dem Benutzer werden pro Mandant ebenfalls eigene Rechte gegeben
Ein "Recht" kann drei Zustände annehmen: Erlaubt / Verweigert / Unbekannt (NULL)
Verweigerung hat Vorrang vor Erlaubnis

Zusätzlich hat ein Benutzer dann noch für jeden Mandanten andere "Einstellungen", die ebenfalls gespeichert werden müssen...

Im Prinzip funktioniert es wie die NTFS-Berechtigungen...

[mjustin]

Zitat von Morphie:

Verweigerung hat Vorrang vor Erlaubnis

Zusätzlich hat ein Benutzer dann noch für jeden Mandanten andere "Einstellungen", die ebenfalls gespeichert werden müssen...

Im Prinzip funktioniert es wie die NTFS-Berechtigungen...

Was ist, wenn ein Benutzer sowohl der "Administrator" Gruppe angehört als auch "Gast oder "Praktikant"? Gehen ihm dann seine Admin-Rechte, soweit die dort auf "DENY" stehen, wieder verloren? Oder kommt hier noch eine Art von Hierarchie oder Reihenfolge (geordnete ACL, und das erste darin gefundene Recht oder Deny "gewinnt") ins Spiel? (Siehe http://security.stackexchange.com/qu...access-dilemma)

[Morphie]

Die Rechte gehen ihm dann verloren.
Allerdings macht es keinen Sinn, einen Administrator in die Gruppe "Praktikaten" zu stecken
Es macht auch keinen Sinn, administrative Aufgaben bei den Praktikaten auf Deny zu stellen. Es gibt wie gesagt auch noch das Recht "NULL / Unbekannt / Unbelegt".

Hat ein Benutzer das Recht in keiner seiner Gruppen und auch in der eigenen Rechteverwaltung nicht, dann hat er diese Berechtigung tatsächlich nicht... (Die Berechtigung steht in allen Gruppen auf NULL)
Wenn in irgendeiner Gruppe ein DENY auftaucht, hat der Benutzer ebenfalls keine Berechtigung auf die Funktion, obwohl diese eventuell in einer anderen Gruppe erlaubt ist.
Wenn die Berechtigung in allen anderen Gruppen auf NULL steht, außer in einer (oder mehreren) auf ALLOW, dann hat er die Berechtigung.

Unsere Standardkonfiguration:
Alle Benutzeraufgaben stehen in der Gruppe "Benutzer" auf ALLOW.
Alle Administrativen Aufgaben stehen in der Gruppe "Administrator" auf ALLOW
Die Gruppen Praktikaten, Gast, Auszubildende usw. sind entsprechend mit DENY eingeschränkt

Der Administrator ist in den Gruppen "Benutzer" und "Administratoren"

Trotzdem gibt es noch die Möglichkeit, einzelnen Benutzern bestimmte Rechte wegzunehmen. Oder einem nicht-Administrator eine administrative Aufgabe zuzuteilen...


edit: Natürlich sichern wir uns aber auch entsprechend ab Es gibt immer ein Administrator-Account, der vollzugriff hat. Sonst ständen wir wohl beim Support das eine oder andere Mal doof da