Application Context verwenden?
hallo,
ich bin gerade am überlegen für einen gute architekturansatz und dabei würde mich eure meinung interessieren.
Kurzerklärung:
Ein Business Layer stellt verschiedenen Funktionen bereit wie z.B. "einchecken eines Dokumentes" - dabei wird einfach gesagt eine Datei in einer DB abgelegt. Weiters sollten alle Funktionen der BL prüfen, ob der aktuelle User überhaupt die Rechte hat, diese Funktion auszuführen - das wird vermutlich als Aspekt via Spring.net implementiert werden.
Bei der Funktion "einchecken" muss diese wissen, im Context welchen Projektes sie sich befindet.
Grund: Das Projekt definiert Regeln, welche beim "einchecken" ausgewertet werden müssen.
Weiters sollte man natürlich immer wissen, im Context welchen Users man gerade mit dem Programm arbeitet -> für die Rechteprüfung.
Mein Ansatz wäre, dass ich eine Klasse für einen "ApplicationContext" erstelle. Diese hält Informationen über User, aktuelle Projekt u.a. Alle Funktionen bekommen nun diesen "Context" als Parameter und wissen so, im Context welchen Users/Projektes sie ausgeführt werden.
Was mir daran nicht gefällt ist, dass ich jeder Funktion den Cotext mitgeben muss.
Ein Singleton, welches den Context hält, geht nicht, da ja mehrere Contexte gleichzeitig mit der selben BL arbeiten können.
Wie würdet ihr das o.g. lösen bzw. was haltet ihr von meinem Architekturansatz?
thx
hannes
Hallo HannesB,
Ein Singleton, welches den Context hält, geht nicht, da ja mehrere Contexte gleichzeitig mit der selben BL arbeiten können.
Weil mehrere Projekte offen sein können oder weil mehrere Benutzer angemeldet sein können?
Sind die Rechte vom Benutzer abhängig oder vom Projekt oder von beidem?
herbivore
hallo "herbivore",
danke für deine Antwort.
zu den Fragen:
Es können mehrere Benutzer angemeldet sein. (genaugenommen dzt. nicht, aber die BL soll später mal eine Serverkomponente werden, dzt. ist diese auf jedem Client deployed und ich will mir hier nix "verbauen")
Rechte sind nur vom Benutzer abhängig.
Hallo HannesB,
ok, dann geht es doch auch eher um einem "UserContext" (oder sogar nur "User") und nicht um einen "ApplicationContext", oder?
Vermutlich muss doch zu jedem Dokument auch klar sein, von welchem User es gerade bearbeitet wird, oder?
Wenn in beiden Fällen ja, dann musst du nur ein Field oder eine Property vom Typ User der Klasse Dokument hinzufügen und entsprechend setzen. Das Dokument musst du sowieso als Parameter übergeben. Die explizite Übergabe der Kontext-Information sparst du dir dadurch.
herbivore
hallo,
ja, der name "UserContext" ist wohl passendern, weil
- ein USER arbeitet mit einem Dokument
- ein USER arbeitet dzt. in einemn bestimmten Projekt mit einem bestimmten Dokument
-> also bei beiden Fällt ja 😉
ABER
Das Dokument und die CheckIn Funktion waren nur ein Beispiel. Natürlich gibt es viel mehr Business Objekte und Funktionen, welche alle in einem Usercontext ausgeführt werden müssen.
Möglichkeiten:
- Allen BL Klassen den Usercontext übergeben
- Userkontext zentral halten + Klassen greifen auf diese Instanz zu
An 1. stärt mich, dass man überall den Usercontext mitgeben muss - enormer Änderungsaufwand
- spricht eigentlich sehr für Sigleton wobei halt das Problem ist, dass es es gleichzeitig mehrere User geben kann.
hmm - je mehr ich darüber nachdenke....eigentlich kann es ja auch sein, dass eine Web Appl. auf die BL zugreift und da hab ich dann immer den User der aktuellen Session - hmmm. Muss noch überlegen, wie man das am gscheitesten macht.
Hat mich einfach interessiert, wie andere das lösen - ist ja imho. ein sehr oft vorkommendes Szenario, dass Programmfunktionen in einem gewissen Kontext (man könnte auch sagen Rahmenbedingungen) ausgeführt werden.
thx
hannes
Hallo Hannes,
da Du den gleichen Terminus (ApplicationContext) verwendet hast, wie wir in unserer Architektur, bin ich auf deine Frage aufmerksam geworden.
Wir haben auch einen ApplicationContext und der Anlass war ziemlich genau der gleiche Grund: wir wollen wissen, welche Rechte der aktuelle Benutzer der Anwendung in der DB hat, was seine letzten Einstellungen und Ansichten waren (das steht bei uns auch in der DB) etc.
Wir haben uns für den Singleton entschieden und aufgrund anderer Architekturmerkmale unseres Frameworks aber kein Problem damit, dass "alle", die etwas vom ApplicationContext "wissen" wollen, diesen ansprechen können:
Unser ApplicationContext implementiert eine Schnittstelle IApplicationContext, damit sind schonmal die Fähigkeiten und Methoden überall "bekannt", denn unsere Contracts (Interfaces) sind in nur wenigen DLL´s zusammengefasst.
Ausserdem haben wir eine Microkernel-Architektur.
Da der Microkernel auch ein Singleton ist und ja ohnehin (als Factory) eine zentrale Rolle in der Anwendung spielt, veröffentlicht er gewisse dezentral nötige Dinge eben als Properties und dazu gehört bei uns eben unter anderem der ApplicationContext.
Daher ist in einem beliebigen Modul folgendes Szenario (kurzgefasst) denkbar und umgesetzt:
public class ContactContext : BusinessContext, IContactContext
{
#region Members
private IMicrokernel microKernel;
#endregion
#region .ctor(s)
public ContactContext()
{
microKernel = KernelLoader.GetMicrokernel();
string author = microKernel.ApplicationContext.Login;
base.CanSave = microKernel.ApplicationContext.HasPermission(eContextPermission.Write);
}
#endregion
}
Hoffe diese Meinung nützt Dir.
Hält irgendjemand diese Architektur für fragwürdig ? - würde mich über Eure Meinungen ebenfalls fruen.
Gruß
Ron
Auch hier eine std Antwort von mir:
Warum benutzt eigentlich niemand den extra für soetwas im FW eingebauten Principal?
Der hosted u.a. schon jetzt einen User(Identity), der beliebig erweitert werden kann.
Er steht Programmweit sowieso schon zur Verfügung....
hi fzelle,
Warum benutzt eigentlich niemand den extra für soetwas im FW eingebauten Principal?
Wir erben den Principal nicht, weil wir von einer anderen Klasse (BusinessContext) erben wollen.
Aus meinem Beispiel geht aber nicht hervor, dass der Principal nicht vielleicht ein Property des ApplicationContexts ist... 😉