Best practice: Benutzerverwaltung mit Datenbankanbindung

[Morphie]

Klar ginge das... Aber genauso könnte meine eigene Anwendung dieses UDP-Broadcast senden
Wie gesagt, eigentlich möchte ich auf eine Zwischenschicht verzichten, da ich Angst um die Performance habe. Im Prinzip besteht unsere Anwendung großteils aus Eingaben / Abrufung von Daten. Es ist also sehr Datenbankorientiert. (sehr viele Selectes und Inserts / Updates)

Ich kenne die Vorteile von Multi-Tier-Anwendungen, halte sie für unsere Anforderungen aber nicht in allen Bereichen für sinnvoll.

[mjustin]

Zitat von Morphie:

Klar ginge das... Aber genauso könnte meine eigene Anwendung dieses UDP-Broadcast senden

Dass man ein einem einzigen Programm sowohl den Client als auch seinen Applicationserver zusammen kompilieren kann ist mir schon klar

Für die maximale Performance kann die direkte Datenbankanbindung natürlich essentiell sein. Applicationserver erfordern ja auch einigen Aufwand, selbst wenn sie nur zustandslose Web Services zuverlässig (und zugleich einfach änderbar) bereitstellen sollen...

[sx2008]

Also es gibt User, Groups und Permissions (Rechte).
Die Permissions kann man den Usern aber auch den Gruppen zuteilen.
Es besteht als einen N:M Beziehung zwischen User und Permissions als auch zwischen Groups und Permissions.

Wenn ein User sich anmeldet, dann sammelt man alle seine Permissions in einer Liste.
Der User kann Mitglied in mehreren Gruppen sein.
Also erhält der User weitere Permissions aus diesen Gruppen.

Eine Permission könnte z.B. sein:

Code:

Permission_Edit_Global_Config (Benutzer darf globale Konfiguration ändern)

Dann gibt es lokal in jedem Formular / Datenmodul eine Zuordnung von Permissions zu bestimmten Properties von Komponenten.
Das könnte z.B. so aussehen:

Delphi-Quellcode:

PanelConfig.Enabled := SecurityManager.HasPermission('Permission_Edit_Global_Config');
QueryPreise.ReadOnly := not SecurityManager.HasPermission('Permission_Change_Prices');
MenuItemDebug.Visible := SecurityManager.HasPermission('Permission_Debug');

Es gibt hauptsächlich 3 Properties, die von Interesse sind: Enabled, Visible und ReadOnly.
Mit Hilfe von RTTI kann man die Zuordnung zwischen Komponenten-Properties und Permissions zur Laufzeit herstellen.

Du kannst es dir aber auch einfach machen und die TMS Security System Komponenten (früher: Uil Security) kaufen.

[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 sx2008:

Also es gibt User, Groups und Permissions (Rechte).
Die Permissions kann man den Usern aber auch den Gruppen zuteilen.
Es besteht als einen N:M Beziehung zwischen User und Permissions als auch zwischen Groups und Permissions.

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.

Neben dem Anbinden von Rechten an GUI Elemente wünsche ich mir ein Delphi eine Möglichkeit sie über Attribute an Methoden zu binden, so wie es das Apache Shiro Framework kann. Dann könnte man in beliebigen Anwendungsarten (Kommandozeile, Service, Webanwendung) unmittelbar auf Ebene der Geschäftslogik die Rechte prüfen, anstatt in der Visualisierungsschicht.

Delphi-Quellcode:

//Will throw an AuthorizationException if none
//of the caller’s roles imply the Account 
//'create' permission
[RequiresPermissions(“account:create”)‏]
procedure openAccount(acct:  Account);
begin
    //create the account
end;

[Stevie]

Zitat von mjustin:

Neben dem Anbinden von Rechten an GUI Elemente wünsche ich mir ein Delphi eine Möglichkeit sie über Attribute an Methoden zu binden, so wie es das Apache Shiro Framework kann. Dann könnte man in beliebigen Anwendungsarten (Kommandozeile, Service, Webanwendung) unmittelbar auf Ebene der Geschäftslogik die Rechte prüfen, anstatt in der Visualisierungsschicht.

Mit method interception geht das.

Allerdings hat das den Nachteil, dass man nicht in der GUI sieht, ob man die Aktion durchführen kann, sondern es kommt erst beim Versuch eine Meldung, dass es nicht geht.

Bei einem RAD Ansatz würde ich wahrscheinlich eher eine eigene TAction Klasse bauen, der man Entsprechende Eigenschaften verpassen kann.