Angenommen, Sie haben drei Ebenen: Benutzeroberfläche, Geschäft, Daten.
Ist das ein schlechtes Design, wenn die Business-Schicht auf Sitzungen zugreifen muss? Etwas daran fühlt sich nicht richtig an. Gibt es Richtlinien, die speziell auf die Web App zugeschnitten sind?
Ich benutze c # 2.0 .net
Ich glaube, dass die Business-Schicht der einzige Ort ist, an dem der Sitzungsdatenzugriff möglich ist, weil er wirklich Teil Ihrer Logik ist. Wenn Sie es in der Präsentationsschicht brennen, ändern Sie den Speicherort der Daten (sagen wir, Sie möchten den Sitzungsstatus nicht mehr verwenden), dann ist es schwieriger, Änderungen vorzunehmen.
Was ich tun würde, wäre für alle Daten, die Sitzungsstatus ist, würde ich eine Klasse erstellen, um den Abruf dieser Daten einzukapseln. Dies wird zukünftige Änderungen ermöglichen.
Bearbeiten: Die Benutzeroberfläche sollte nur für Folgendes verwendet werden: 1. Rufen Sie die Business-Schicht auf. 2. Interagieren Sie mit dem Benutzer (Nachrichten und Ereignisse). 3. Manipulieren Sie das visuelle Objekt auf dem Bildschirm.
Ich habe gehört, dass Leute den Sitzungsdatenzugriff als Teil der Datenschicht betrachten, und dies ist semantisch und hängt davon ab, was Sie als Datenschicht betrachten.
Nein. Wenn Sie einen "Controller" Layer hatten, sollten Sie dort darauf zugreifen. Holen Sie sich die benötigten Informationen aus der Sitzung und übergeben Sie sie an Ihre Business-Schicht.
Seufz.
Der breite Konsens wird nein sein; die Business-Schicht und die Controller / Web-Schicht sollten anders gepflegt werden, weil sie separate Anliegen sind.
Tatsache ist, dass Sie dies als eine "Reinheit vs. Realität" -Frage bezeichnen, die unglaublich kurzsichtig und leicht unausstehlich ist. Es widerspricht auch dem Punkt, die Frage zu stellen; Wenn Sie die präsentierten Meinungen nicht berücksichtigen, warum sollten Sie sie dann anfragen?Es stimmt, dass es etwas mehr Aufwand erfordert, mehr Zeit zu sparen und letztendlich ein bisschen mehr kostet, wenn man die Dinge etwas vorsichtiger auseinander nimmt. Es ist auch wahr, dass Sie möglicherweise keinen unmittelbaren Nutzen daraus ziehen können. Eine Fülle von Schluchtromanen, die mehrere Jahrzehnte lang von einer großen Anzahl von Programmierern geteilt wurden, legt jedoch nahe, dass Ihre so genannte "Reinheit", wenn möglich, die Schmerzen in fünf Jahren reduziert. Meine Güte; Sie müssen wirklich knutschen und ein wenig Refactoring tun, und es ist nicht im entferntesten angenehm wegen all der Risse, durch die Ihre Verantwortlichkeiten sickern.
Eine etwas bessere Möglichkeit, sich die Schichten für eine Webanwendung vorzustellen, könnte die Darstellung, Interaktion, Geschäftsregeln und Daten sein; von oben nach unten. Ihre Daten sind die Datenbank, der Datenzugriff usw. und die Geschäftsregeln erzwingen zusätzliche Einschränkungen für diese Daten, behandeln Validierungen, Berechnungen usw. Die Interaktion verzweigt dann zwischen der Darstellungsschicht (die im Grunde Ihre Benutzeroberfläche ist) und der Geschäftslogik. Ausführen der Anwendungsfälle, die Ihre Anwendung steuern.
Bis zu diesem Punkt ist die Benutzerschnittstelle allesamt immateriell; Es spielt keine Rolle, ob der Benutzer z. B. Kundendaten in einer Befehlszeilenanwendung eingibt oder ein mehrseitiges Webformular mit in der Sitzung gespeicherten Daten navigiert. Nehmen wir an, Sie wählen das Letztere. kleben Sie ein Web-Front-End drauf. Jetzt geht es darum, relativ einfachen Code zu schreiben, um die angeforderten Daten abzurufen und sie dem Benutzer zu präsentieren. Der Punkt ist, Ihre Webanwendung; das Frontend, das ist Ihre gesamte Benutzeroberfläche; Sitzungen und alle. Nur an dem Punkt, an dem Sie bereit sind zu sagen, "hey, lasst uns diese Kundendaten in die Datenbank stecken", rufen Sie diese ach so liebevoll gestalteten Service-Layer auf und geben jedes Bit an Information weiter, das Ihre Webanwendung hat verstaut; die Benutzereingabe, der Name des Benutzers, der die Änderung vornimmt; all dieser Mist. Und deine Service-Schicht geht damit um. Oder, alternativ, Hündinnen, weil Sie ein Pflichtfeld vergessen haben.
Da Sie die Dinge sauber getrennt haben, können die Eingeweide Ihrer Anwendung, wie von anderen vorgeschlagen, in jeder anderen Anwendung umgestaltet (oder "geborgt") werden, und die Serviceebene bleibt, statusfrei, sauber und bereit, mit den Dingen umzugehen. Und es macht Ihre Validierung, und so ist Ihre Validierung überall konsistent. Aber es weiß nicht, wer sich im Web-Frontend oder in der Konsolenanwendung oder der ausgeklügelten Rich-Client-Anwendung, die auf einem Terminal ausgeführt wird, angemeldet hat, und das ist auch egal, da dieses Detail nur für diese Anwendungen wichtig ist.
Müssen Sie eine neue Validierungsregel hinzufügen? Kein Problem; Sorgen Sie dafür, dass die Serviceschicht die Validierung durchführt, und sorgen Sie dafür, dass die Probleme der Benutzeroberfläche oben in der Kette weiter oben behandelt werden. Müssen Sie die Art und Weise ändern, wie etwas berechnet wird? Ändern Sie das auf der Business-Schicht. Nichts anderes muss beeinflusst werden.
Ich halte eine unnötige Nutzung von Session für einen Code-Geruch im Allgemeinen, oft sind Querystrings, Cookies und Viewstate leichter und haben einen besseren "Scope"
Was die Sitzungsrolle in einer Geschäftsschicht betrifft, hängt es davon ab, welchen Architekturguru Sie gerade lesen. Wenn die Business-Logik-Ebene ein Ort für Code ist, der von der Benutzeroberfläche unabhängig ist, ist die Einführung von Sitzung keine Sache für die Business-Ebene.
Beispielsweise in einer Konsolenanwendung, einer ASP.NET-Webanwendung, einem Windows-Dienst und einer Windows Forms-App - nur ASP.NET verfügt über eine Sitzung.
Das heißt, die Unterstützung mehrerer Benutzeroberflächen ist eine stark überbewertete Funktion, und es bedarf keiner perfekten Voraussicht, um abzuschätzen, ob Sie Ihre App jemals auf eine andere Benutzeroberfläche portieren werden. Wenn Sie sehr zuversichtlich sind, dass Ihre Logik nur in einer ASP.NET-App ab sofort und für immer ausgeführt wird, ist dies in Ordnung.
Eine Ausnahme wäre Unit Testing. nUnit-Test-Runner stellen eine andere Benutzeroberfläche dar und es ist schwierig, Request, Response, Session, Application, etc. zu simulieren.
Wenn Sie die drei aufgelisteten Layer beibehalten, ist die Ebene "Business" wahrscheinlich am besten geeignet, um mit Session-Objekten umzugehen.
Da eine Sitzung mehr damit zu tun hat, dass das eigentliche Framework die Anwendung verknüpft als jede tatsächliche Geschäftslogik, möchten Sie möglicherweise eine Steuerschicht erstellen, die Daten aus dem Session-Objekt in Geschäftsdateneingaben in die Business-Schicht umsetzt / p>
Ich denke, es hängt von der Nutzung ab, aber ja, wir greifen immer auf die Sitzung von unserer Business-Schicht zu. Es gibt auch hier ein Argument "Reinheit gegen Realität".
Zum Beispiel haben wir in unserer Anwendung eine Datenbank pro Client, aber eine Codebasis. So haben wir die Client-Informationen in der Sitzung für jeden Benutzer. Sicher, wir könnten diese Daten dann in der Webschicht aus der Sitzung herausholen und dann an die Business-Schicht übergeben. Natürlich kümmert sich die Business-Schicht nicht einmal darum, aber sie wird von der Datenschicht benötigt, um sich mit der richtigen Datenbank zu verbinden. Dann müsste die Business-Schicht sie an die Datenschicht übergeben. Scheint wie viele Parameter, die ohne guten geschäftlichen Grund überschritten werden. In unserem Fall überprüft unsere Datenschicht das Session-Objekt für die Verbindungszeichenfolge und läuft von dort. Wir haben das Problem, keine Sitzung zu haben, wenn es sich nicht um eine Web-App handelt (und wir haben Windows-Dienste und .exe-Hilfsanwendungen), wie folgt programmiert:
%Vor%Der Zugriff auf die Sitzung von der Business-Schicht ist definitiv ein Code-Geruch.
Wenn Sie die Business-Schicht wie angegeben "wechseln" müssen, müssen Sie sich nur über Ihre Präsentationsschicht oder den Controller Gedanken darüber machen, was die Sitzungsvariable ist.
Beispiel: Sie möchten einen Satz von Objekten für eine Sitzungsvariable und einen anderen Satz für eine andere Variable verwenden. Ihr Controller könnte eine Service-Schicht aufrufen und die Variable übergeben. Die Serviceschicht würde dann das entsprechende Geschäftsobjekt zurückgeben.
Ihre Business-Schicht weiß nichts über die Sitzung in dem Sinne, dass Ihre Präsentationsebene nichts darüber weiß, wie Sie sich mit der Datenbank verbinden.
Das Sitzungsobjekt ist an eine bestimmte UI-Implementierung gebunden. Daher ist es ein Gestank, dass Ihre Business-Schicht in Ihrer Sitzung abgestorben ist.
Außerdem sollten Sie wahrscheinlich in der Lage sein, Ihre Business-Schicht in einem Unit-Test zu testen. Wie werden Sie das tun, wenn Abhängigkeiten von einer Sitzung bestehen?
Tags und Links c# session business-logic