Vielen Dank schon einmal für die schnellen Antworten!
Das ist schonmal ein interessanter Ansatz. Es ist eigentlich perfekt für Aktionen die ausgeführt werden sollen wie "Drucke einen Report" oder "Pausiere die menscheneinsaugende Turbine". Ich dachte allerdings größtenteils an Settings, also reine Werte anzeigen und ggf. Editieren.
Ich verstehe nicht, was
Auf Clientseite ist das in den Basisklassen fest verankert und muss nicht geändert werden bei neuen / anderen Inhalten
genau beudetet. Ich müsste doch trotzdem ständig manuell nach einem passenden Recht suchen, schauen wie es um den aktuellen Nutzer bestellt ist und dementsprechend handeln. Wenn ich eine Klasse nun um neue Properties erweitere, muss ich doch auch ebenso viele neue Rechte hinzudichten? Oder habe ich was falsch verstanden?
in der Praxis kein User in einer unternehmesweiten "Fachlichkeit" überall einen bestimmten/gleichen Level hat/ erreicht.
Du bekommst also irgendwann Probleme, weil der Müller (der König aus dem Lager), die Feinheiten in der Produktion justiert...
Das stimmt, daran habe ich noch nicht gedacht. Die Software ist allerdings recht speziell, so unterschiedliche Qualifikationen sollten da nicht auftreten. Zumindest noch nicht...
Packe die Rechteverwaltung in ein Filter für die entsprechenden Objekte, das die Aufrufe filtert und im Verletzungsfall eine
Exception wirft. Der "Nutzer" bekommt die geschützten Objekte aus einer Factory, die passenden Filter (evtl. mehrere) entsprechend seiner Rolle(n) erstellt.
Aber entweder müsste ich den Quellcode dieser Filterfabrik jedes mal anpassen, wenn sich an den Objekten etwas ändert, oder ich das Ding ist so flexibel, dass es Getter und Setter dynamisch zusammenbaut. Ein ganz schönes Monsterteil.
Das wäre mit Sicherheit die feine englische Art. Aber Benutzer in Gruppen stecken, Benutzerrechte überschreiben evtl. wieder Gruppenrechte, Benutzer in mehreren Gruppen - Das bekomme ich in gefordertet Zeit niemals hin, ich muss bei etwas einfacherem bleiben
Die "große" Lösung wäre die Speicherung in der Datenbank, da kann der Kunde sich zu Tode konfigurieren, Du mußt nur nachschauen ob für die gewünschte Funktionalität auch eine Berechtigung vergeben wurde.
Gerade das Nachschauen sieht für mich aus wie Gewitterwolken am Horizont. An den Objekten selbst wird sich über die nächste Zeit viel ändern, das kann ich riechen. Dieses Nachschauen möchte ich nicht manuell machen. Der Kunde bekommt eine neue Softwareversion, die Objekte haben etliche neue Properties, seine Config-Datenbank bleibt natürlich unangetastet. Jetzt haben alle neuen Dinge ein Default-Verhalten, bsp. von jedem les- und schreibbar.
Bonus:
Man sollte noch ausführen, dass die Anwendung aus mehreren, miteinander kommunizierenden Prozessen besteht. Im Endeffekt ist es eine Master-Anwendung (inkl. grafisches Frontend) mit mehreren Slave-Prozessen, die nur auf Anfragen antworten und nicht von sich aus sprechen. Aus diesen Prozessen möchte ich Werte auslesen und ggf. setzen. Und diese Prozesse sollen sich auch nicht mit Datenbanken herumschlagen.
Deshalb war (und ist) es mir immer noch sehr sympathisch, per Attribute im Quelltext standardmäßige Berechtigungswerte vorzugeben, der Benutzer soll das in der Master-Anwendung anpassen können.