Schon von Anfang an hadere ich mit mir, was die Modellierung der Benutzerklassen angeht (siehe anfängliche Posts...). Wie einigen aufmerksamen Lesern dieses Blogs bekannt sein dürfte, ist das Datenmodell nun so gestaltet, dass jede Entität, die ind er Wahren Welt auch ein auch ein Benutzer "ist", nun ein Benutzerobjekt aggregiert. Wenn ein Benutzer beispielsweise gleichzeitig einen E-Mail-, FTP- und Systemaccount hat, so sind das eben drei verschiedene Entitäten, die allesamt dasselbe Benutzerobjekt aggregieren. Dass es auch mit diesem Design zu Problemen kommen würde, war ja von Anfang an sonnenklar. Denoch werde ich diese Linie weiter verfolgen, zumal ja schon ein größerer Teil der Applikation darauf aufbaut. Doch nun gab's zwei kleine Änderungen:
- Entgegen aller Regeln der Redundanzvermeidung und Normalisierung wurde im
Userein Fremdschlüssel auf denClientgelegt. So kommt man vom Benutzer aus wenigstens einfach an den "Besitzer", was ansonsten mit ganzen drei Joins bewerkstelligt werden musste. FtpAccountsController,EmailAccountsControllerundSystemAccountControllersind nun allesamtKindsklassenvon UsersController. Alles was man mit einem User machen kann, kann man logischerweise auch mit den anderen User-Arten machen -- darum dieser Schritt.
Die Klassenhierachie für die Benutzertypen schaut also nun so aus:
Wer sich über den Einschub von Consolvix::Application wundert, dessen Verwunderung sei hoffentlich mit der Erklärung besänftigt, dass ich das nicht etwa gemacht habe um die Fläche im Klassendiagramm etwas weiter aufzufüllen, sondern einfach um im ApplicationController etwas Übersicht zu schaffen. Alle privaten und internen Funktionen stehen nun weitestgehend in Consolvix::Application, während im (Application)Controller im Wesentlichen nur noch Actions stehen, die der Besucher direkt aufrufen kann.
Und was um alles in der Welt hat das alles mit der 42 zu tun? Nun, Dies ist der 42. Eintrag. In dem Sinne Lang lebe das Universum! ;-)
