Sollte Geschäftsschicht der Anwendung in der Lage sein Objekt Session zugreifen?

Question

Angenommen, Sie haben 3 Schichten:. UI, Geschäftsleben, Daten

Ist das ein Zeichen für schlechtes Design, wenn Business-Schicht Sessions zugreifen muss? Etwas über es fühlt sich nicht richtig. Gibt es Richtlinien speziell auf Web-App zugeschnitten folgen?

Ich verwende c # 2.0 .net

Answer 1

Mein Gefühl ist, dass die Business-Schicht der einzige Ort ist, um die Sitzungsdaten Zugriff zu setzen, weil es wirklich einen Teil Ihrer Logik. Wenn Sie es in der Präsentationsschicht backen, dann, wenn Sie ändern, in dem die Daten gespeichert werden (können sagt, Sie nicht mehr wollen Sitzungsstatus verwenden), dann macht eine Änderung schwieriger ist.

Was ich tun würde, ist für alle Daten, die Sitzungszustand ist, würde ich eine Klasse erstellen, das Abrufen der Daten zu kapseln. Dies wird für zukünftige Änderungen ermöglichen.

Edit: Die Benutzeroberfläche sollte nur verwendet werden, um wie folgt vorgehen: 1. Rufen Sie an der Business-Schicht. 2. Interagieren mit dem Benutzer (Nachrichten und Ereignisse). 3. Manipulieren visuelles Objekt auf dem Bildschirm.

Ich habe gehört, die Menschen betrachten den Sitzungsdatenzugriff als Teil der Datenschicht, und dies ist semantisches und hängt davon ab, was Sie die Datenschicht in Betracht ziehen.

Answer 2

Nein. Wenn Sie eine „Controller“ Schicht haben, sollten Sie es dort zugreifen. Man bekommt, was man von der Session brauchen und geben Sie es aus, um Ihre Business-Schicht.

Answer 3

Sigh.

Der breite Konsens wird nicht sein; die Business-Schicht und die Steuerung / Bahnschicht sollte anders gehalten werden, weil sie getrennte Bedenken.

Die Tatsache ist, Sie scheinen dies als „Reinheit gegen Realität“ Frage zu beschriften, die unglaublich kurzsichtig ist und etwas widerlich. Es trotzt auch den Punkt, die Frage zu stellen; wenn Sie nicht vorgestellt gehen die Meinungen zu berücksichtigen ist, dann warum sie erbitten?

Es ist wahr, dass die Dinge aus einem wenig vorsichtiger vorne erfordert mehr up-front Aufwand, mehr Zeit, Trennung und schließlich ein wenig mehr kosten kann. Es ist auch wahr, dass Sie nicht in der Lage sein zu tun, so dass jeder unmittelbaren Nutzen zu erkennen. Allerdings schlägt eine Fülle von sob Geschichten unter einer großen Anzahl von Programmierern für mehrere Jahrzehnte geteilt, dass, soweit möglich, Ihre sogenannte „Reinheit“ reduziert den Schmerz, wenn fünf Jahre auf der ganzen Linie; Meine Güte; Sie müssen zupacken wirklich und ein wenig Refactoring zu tun, und es ist nicht aus der Ferne angenehm, weil alle Ritzen, durch die Ihre Aufgaben sickert werden.

Eine etwas bessere Möglichkeit, die Schichten für eine Web-Anwendung von Vorstellungsvermögen könnte es sein, Präsentation, Interaktion, Geschäftsregeln und Daten zu prüfen; von oben nach unten. Ihre Daten ist die Datenbank, Datenzugriff usw. und die Geschäftsregeln erzwingen keine zusätzlichen Einschränkungen auf diesen Daten, Griff valiation, Berechnung usw. Interaktion verzweigt sich dann zwischen der Präsentationsschicht (die im Grunde ist die Benutzeroberfläche) und die Business-Logik, Durchführen der Anwendungsfälle, die Ihre Anwendung fahren.

Bis zu diesem Punkt ist die Benutzeroberfläche alle unwesentlich; es spielt keine Rolle, wenn die Eingabe des Benutzers, sagt, Kundendaten in einer Befehlszeilen-Anwendung, oder ein mehrseitige Web-Formular navigieren mit in der Session gespeicherten Daten. Angenommen, Sie haben die letztere wählen; Stick einen Web-Frontend darauf. Nun, was Sie besorgt sind mit schreiben relativ einfachen Code zu handhaben, die angeforderten Daten zu holen und sie für den Benutzer. Der Punkt ist, Ihre Web-Anwendung; das Front-End, , dass ist Ihre gesamte Benutzeroberfläche; Sitzungen und alle. Nur an dem Punkt, wo Sie bereit sind, zu sagen: „Hey, lasst uns, dass Kundendaten in die Datenbank bleiben“ gehen Sie und rufen Sie diese ach so liebevoll gestaltete Service-Layer, jedes Bit an Information vorbei, dass Ihre Web-Anwendung bekam gebunkert; die Benutzereingabe, der Name des Benutzers, die Änderung vorzunehmen; so ein Scheiß. Und Ihre Service-Layer umgeht. Oder alternativ Hündinnen weil vergessen hat, ein Pflichtfeld.

Weil du sauber Dinge getrennt habe aus, die Eingeweide Ihrer Anwendung können, wie andere vorgeschlagen haben, umgebaut werden (oder „ausgeliehen“) in einer anderen Anwendung zu verwenden, und die Service-Schicht bleibt, staatenlos, sauber und bereit, Dinge zu behandeln. Und es tut Ihre Validierung und so Ihre Validierung ist überall konsistent. Aber es nicht weiß, wer in das Web-Frontend angemeldet ist, oder der Konsolenanwendung oder der Phantasie Rich-Client-Anwendung auf einem Terminal ausgeführt wird, und es kümmert sich nicht darum, weil das Detail wichtig ist, nur auf diese Anwendungen.

Sie benötigen eine neue Gültigkeitsregel hinzufügen? Kein Problem; macht die Service-Schicht die Validierung zu tun, und behandelt die Benutzeroberfläche betrifft, wie notwendig höher in der Kette. Sie möchten die Art und Weise etwas ist berechnet ändern? Ändern Sie, dass bei der Business-Schicht. Nichts anderes muss betroffen sein.

Answer 4

Riecht mir komisch vor. Vielleicht benötigen Sie eine Präsentationsschicht die Sitzung und andere Stateful Informationen zu verwalten?

Answer 5

Ich denke, die Business-Logik nicht zu einer Präsentation Wahl gebunden werden soll, und wenn Session lebt in dieser Stufe wird es gebunden werden.

Answer 6

ich unnötige Verwendung von Session betrachte ein Code Geruch im Allgemeinen sein, oft querystrings, Kekse und Ansichtszustand ist Lighterweight und hat eine besseren ‚Umfang‘

In Bezug auf Sessions Rolle in einem Business-Tiere, es hängt davon ab, welche architektonische Guru Sie im Moment gerade lesen. Wenn die Geschäftslogikebene ein Ort für Code unabhängig von UI ist, dann Session ist nicht eine Sache, um in das Business-Tier einzuführen.

Zum Beispiel in einer Konsole app, ein ASP.NET Web-App, ein Windows-Dienst, und ein Windows-Anwendung Forms -. Nur ASP.NET Session hat

Wie gesagt, in der Lage zu sein Mutliple UIs zu unterstützen, ist ein sehr überschätzten Feature und es dauert nicht perfekte Voraussicht zu schätzen, wenn Sie je Port Ihre App auf eine andere Benutzeroberfläche. Wenn Sie sehr zuversichtlich sind, dass Ihre Logik nur in einem ASP.NET-App ab sofort laufen wird und für immer, dann ist es in Ordnung.

Eine Ausnahme würde Unit-Tests sein. nUnit Test Läufer bilden eine andere UI und es ist schwer Request, Response, Session, Anwendung zu simulieren, etc.

Answer 7

Wenn Sie die drei Schichten halten Sie aufgelistet, die ‚Business‘ Schicht wahrscheinlich die am besten geeignet wäre, mit Session-Objekten zu tun hat.

Da eine Sitzung mehr mit dem tatsächlichen Rahmen zu tun, um die Anwendung zu binden zusammen als mit einer tatsächlichen Geschäftslogik, Sie mögen eine Steuerschicht zu schaffen, die Daten aus dem Session-Objekt auf Geschäftsdaten Eingaben in der Business-Schicht übersetzt.

Answer 8

Ich denke, es ist an der Nutzung abhängt, aber ja, wir zugreifen Sitzung aus unserer Business-Schicht die ganze Zeit. Es gibt ein „Reinheit vs. Realität“ Argument auch hier.

Zum Beispiel in unserer Anwendung haben wir eine Datenbank pro Client, sondern eine Code-Basis. So haben wir die Client-Informationen in der Sitzung für jeden Benutzer. Natürlich könnten wir dann auch außerhalb der Sitzungen in der Web-Schicht, dass die Daten ziehen und sie dann an die Business-Schicht überliefern. Natürlich ist die Business-Schicht nicht einmal darum kümmern, aber es von der Datenschicht benötigt wird, um die richtige Datenbank zu verbinden. So würde die Business-Schicht müssen sie an die Datenschicht zu überliefern. Scheint, wie viele Parameter für kein gutes Geschäft Grund vorbei. In unserem Fall prüft unsere Datenschicht das Sitzungsobjekt für die Verbindungszeichenfolge und läuft von dort aus. Wir codiert, um das Problem der nicht-Session, wenn es nicht eine Web-App (und wir haben Windows-Dienste und Exe-Helfer-Anwendungen) wie folgt:

protected virtual string GetConnectionString()
{
string connectionString;
string connectionStringSource;

//In app.config?
if (ConfigurationManager.AppSettings[_ConnectionStringName] != null &&
   ConfigurationManager.AppSettings[_ConnectionStringName] != "")
{
   connectionString = ConfigurationManager.AppSettings[_ConnectionStringName];
   connectionStringSource = "Config settings";
}
//Nope? Check Session
else if (null != HttpContext.Current && null != HttpContext.Current.Session &&
   null != HttpContext.Current.Session[_ConnectionStringName])
{
  connectionString = (string)HttpContext.Current.Session[_ConnectionStringName];
  connectionStringSource = "Session";
}
//Nope? Check Thread
else if (null != System.Threading.Thread.GetData(
      System.Threading.Thread.GetNamedDataSlot(_ConnectionStringName)))
{
   connectionString = (string)System.Threading.Thread.GetData(
          System.Threading.Thread.GetNamedDataSlot(_ConnectionStringName));
   connectionStringSource = "ThreadLocal";
}
else
{
   throw new ApplicationException("Can't find a connection string");
}

if (debugLogging)
   log.DebugFormat("Connection String '{0}' found in {1}", connectionString, 
          connectionStringSource);

return connectionString;
}

Answer 9

die Sitzung von der Business-Schicht Zugriff ist auf jeden Fall ein Code Geruch.

Wenn Sie die Business-Schicht auf ‚Schalter‘ wie gesagt, Ihre Präsentationsschicht oder Controller ist alles, was Grund zur Sorge über das, was das Session-Variable ist.

Zum Beispiel, sagen Sie eine Reihe von Objekten für ein Session-Variable und einen anderen Satz für eine andere Variable verwendet werden sollen. Ihr Controller könnte eine Dienstschicht nennen und in den Variablen übergeben. Die Service-Schicht würde dann wieder das entsprechende Business-Objekt.

Ihre Business-Schicht hat kein Unternehmen etwas über die Sitzung im gleichen Sinne zu wissen, dass Ihre Präsentationsschicht kein Geschäft zu wissen, hat darüber, wie Sie an die DB einer Verbindung herstellen.

Answer 10

Das Sitzungsobjekt ist an eine bestimmte UI Implementierung gebunden, so zu Ihrer Sitzung starb Ihr Unternehmen Schicht ist ein Geruch.

Plus, sollten Sie wahrscheinlich in der Lage sein, um Unit-Test Ihre Business-Schicht - wie wollen Sie das tun, wenn es Abhängigkeiten auf einer Sitzung

?