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.
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.