Globale Variablen/Abhängigkeiten = Böse... Und nu?

[p80286]

Zitat von Phoenix:

Dazu ist es am einfachsten, den jeweils entsprechend präparierten Fake-User für den Test reinzugeben.

Irgendwas habe ich da nicht verstanden, genau dafür gibt es die Benutzerverwaltung. Eigentlich sollte der Arbeitsteil nur Rechte kennen, der Benutzer dahinter sollte **egal sein.

Gruß
K-H

[Sir Rufo]

Abhängigkeit und schwer testbar

Delphi-Quellcode:

unit FooUnit;

interface

type
  TFoo = class
    property Value : string;
  end;

function Foo : TFoo;

implementation

var
  _Foo : TFoo;

function Foo : TFoo;
begin
  if not Assigned( _Foo ) then
    _Foo := TFoo.Create;
  Result := _Foo;
end;

end.

Delphi-Quellcode:

unit BarUnit;

interface

uses
  FooUnit;

type
  TBar = class
    function GetValue : string;
  end;

implementation

function TBar.GetValue : string;
begin
  Result := Foo.Value;
end;  

end.

Das sollte man besser so machen:

Delphi-Quellcode:

unit BarUnit;

interface

uses
  FooUnit;

type
  TBar = class
  private
    FFoo : TFoo;
  public
    constructor Create( AFoo : TFoo );
    function GetValue : string;
  end;

implementation

constructor TBar.Create( AFoo : TFoo );
begin
  inherited;
  FFoo := AFoo;
end;

function TBar.GetValue : string;
begin
  Result := FFoo.Value;
end;  

end.

Jetzt kann TBar auch mit unterschiedlichen TFoo -Instanzen getestet werden.

[Dejan Vu]

Zitat von p80286:

genau dafür gibt es die Benutzerverwaltung. Eigentlich sollte der Arbeitsteil nur Rechte kennen, der Benutzer dahinter sollte **egal sein.

Ersetze 'User' durch 'Permissions'. Dann kennt das Businessobjekt nur Permissions. Genaugenommen ist das sogar besser, denn was interessiert es das Businessobjekt was das konkret für ein User ist.

Aber die 'Benutzterverwaltung' ist hier auch viel zu fett. Ich brauch an der Stelle keine Verwaltung, sondern nur den Scope/Kontext, der weiß, mit welchen Rechten gearbeitet wird.

Zitat von Sir Rufo:

Abhängigkeit und schwer testbar...

Sobald Du ein Mockingframework hast, das Dir deine statische Klassen mocken kann, ist das wurscht (Gibt es das für Delphi?).

Da imho jede sauber designte Klasse gut (ohne Mocks) testbar ist, aber nicht jede gut testbare Klasse automatisch sauber designt ist, würde ich das Argument 'lässt sich gut/schlecht testen' etwas nach hinten schieben, aber wirklich nur ein wenig. Wichtiger ist für mich: Ist die Klasse flexibel, erweiterbar, robust und wiederverwendbar?

Halten wir also fest:
1. Globale Abhängigkeiten auch auf Kosten der Tipparbeit durch DI auflösen.
2. Die nun umständlichen Instantiierungen über eine Factory abbilden und damit den Overhead verbergen.
3. Abhängigkeiten nur durch Interfaces abbilden.

So sieht das doch wirklich gut aus.
Im Falle des 'Users/Permission' sieht es in der Praxis ganz einfach so aus:
Das Businessobjekt (oder einfacher: die konkrete Aktion) kann in der Anwendung nur von einem Benutzer mit ausreichenden Rechten ausgeführt werden. Fein.

Aber in einem Batchprozess möchte ich gerne (oder ich muss) auf diese Rechte pfeifen. Ich will mir keinen Batchuser zusammenfriemeln, der bestimmte Rechte hat, wobei meine 'Benutzerverwaltung' vielleicht so gemein ist, aus Sicherheitsgründen zu verbieten, das jemand zwei bestimmte Rechte gleichzeitig innehat und das genau die sind, die ich gerade benötige.

Also baue ich mir in meinem Batchprozess meinen Pseudouser (also eine Klasse, die das IUser/IPermissions-Interface implementiert) nach und habe genau das, was ich wollte: Einerseits ein BO, das im Kontext der Anwendung und Aufgerufen durch ein Kommando genau die Sicherheit bietet, die ich brauche, aber sonst eine extrem flexible Klasse, deren Abhängigkeiten im Konstruktor für jeden sichtbar sind und die ich so flexibel wie möglich verwenden kann.

Wirklich? Fast, denn die Schnittstelle (hier wirklich: das Interface) der Abhängigkeiten sollte nur genau die Properties beinhalten, die für die Durchführung dieser Aufgabe wirklich notwendig ist.

[p80286]

Zitat von Dejan Vu:

Aber in einem Batchprozess möchte ich gerne (oder ich muss) auf diese Rechte pfeifen. Ich will mir keinen Batchuser zusammenfriemeln, der bestimmte Rechte hat, wobei meine 'Benutzerverwaltung' vielleicht so gemein ist, aus Sicherheitsgründen zu verbieten, das jemand zwei bestimmte Rechte gleichzeitig innehat und das genau die sind, die ich gerade benötige.

Warum bitteschön sollten für einen batch"User" andere Regeln gelten wie für einen "normalen Dialog User". Entweder es ist für alle Benutzer bzw. Prozesse ein entsprechendes Regelwerk definierbar oder aber da hat jemand seine Hausaufgaben nicht gemacht/machen können.

Gruß
K-H

[Sir Rufo]

Zitat von p80286:

Zitat von Dejan Vu:

Aber in einem Batchprozess möchte ich gerne (oder ich muss) auf diese Rechte pfeifen. Ich will mir keinen Batchuser zusammenfriemeln, der bestimmte Rechte hat, wobei meine 'Benutzerverwaltung' vielleicht so gemein ist, aus Sicherheitsgründen zu verbieten, das jemand zwei bestimmte Rechte gleichzeitig innehat und das genau die sind, die ich gerade benötige.

Warum bitteschön sollten für einen batch"User" andere Regeln gelten wie für einen "normalen Dialog User". Entweder es ist für alle Benutzer bzw. Prozesse ein entsprechendes Regelwerk definierbar oder aber da hat jemand seine Hausaufgaben nicht gemacht/machen können.

Gruß
K-H

Gut, das ist ja z.B. bei Datenbanken ein bekanntes Szenario: Benutzer X darf die Tabellen nur lesen, aber über eine SP darf er doch etwas hineinschreiben.

Allerdings, wenn für die Aktion TuWas die Berechtigungen egal sind, dann prüft diese Aktion die Berechtigungen einfach nicht.

[p80286]

Zitat von Sir Rufo:

Gut, das ist ja z.B. bei Datenbanken ein bekanntes Szenario: Benutzer X darf die Tabellen nur lesen, aber über eine SP darf er doch etwas hineinschreiben.

Es könnte sein, daß über die SP die Art der Daten beschränkt wird, was über die gängigen Berechtigungen nicht vernünftig lösbar sein kann.
Aber abgesehen davon, ist das meiner Meinung nach Schusseligkeit beim Design oder aber die allgegenwärtige Nachfrickelei.
(bevor mir jetzt hier der kragen platzt sehe ich mal zu, daß ich meine Arbeit gemacht kriege)

Gruß
K-H