Sollte Service-Schicht haben Zugriff auf HttpContext?

Question

Ich baue eine Anwendung, die grob dem Repository-Muster folgt, mit einer Service-Schicht oben drauf, ähnlich wie frühe Versionen von Conery's MVC Storefront.

Ich muss eine Seite implementieren, die alle Benutzer außer dem aktuellen Benutzer zurückgibt. Ich habe bereits GetUsers()-Methoden auf der Repository- und der Service-Ebene, die Frage ist also, wo ich das "außer für den aktuellen Benutzer" anwenden soll.

Sollte die Serviceschicht den HttpContext kennen und somit diese Regel anwenden? Ich bin versucht, nur in den aktuellen Benutzer (id) aus dem Controller zu dieser Service-Methode übergeben, aber es scheint sauberer, wenn die Service-Schicht HttpContext-bewusst war und könnte dies auf seine eigene tun.

Eine offensichtliche Alternative wäre, diese Regel direkt im Controller anzuwenden, aber von dieser Idee bin ich einfach nicht begeistert...

---

Edit - nur um die Antworten zu kommentieren: Ich sehe die Probleme mit der umgekehrten Abhängigkeit, die ich völlig übersehen habe. Ich markiere Mehrdad's als die Antwort aufgrund von Stimmen, aber jeder hat wirklich eine wertvolle Antwort geliefert, die es wert ist, gelesen zu werden!

Answer 1

Auf keinen Fall. Meine Denkweise beim Entwerfen dieser Art von Dingen ist so: Ich gehe davon aus, dass ich eine Windows-basierte Anwendung zusammen mit der Web-Anwendung schreiben muss und versuche, die Abhängigkeit von Web-spezifischen Dingen zu minimieren. Übergabe von HttpContext direkt die Kopplung Ihrer Dienstschicht mit Ihrer Web-UI-Schicht erhöhen, was nicht ideal ist.

Answer 2

Sie sollten no eine umgekehrte Abhängigkeit zwischen Ihrer Dienstschicht und der Webebene schaffen. Stellen Sie sich vor, Sie möchten Ihre Dienstschicht erweitern, um mit einer formularbasierten Anwendung oder einem Windows-Dienst zu arbeiten. Jetzt müssen Sie die Web-Abhängigkeit umgehen, um dieselben Methoden zum Laufen zu bringen, oder Sie duplizieren einen (vielleicht kleinen, aber dennoch doppelten) Code. Es wäre besser, die Benutzerkennung in etwas Nützliches im Kontext der Dienstschicht zu extrahieren und diesen Wert in der Dienstschicht zu verwenden. Die Handhabung der Filterung auf der Website ist auch akzeptabel, obwohl, wenn Sie es mehr als einmal tun, müsste es in einem gemeinsamen Ort refactored werden und die Service-Schicht ist der natürliche Ort dafür.

Answer 3

Ich halte es für eine gute Praxis, eine benutzerdefinierte AppContext-Klasse zu erstellen, die mein aktuelles Benutzerobjekt (sowie andere kontextbezogene Daten) enthält. Diese Klasse hat keine Verweise auf System.Web. Alle Servicemethoden, die kontextabhängig sein müssen, sollten einen AppContext-Parameter haben (z. B. zur Überprüfung von Sicherheitsrechten oder zum Abrufen des aktuellen Benutzers wie in Ihrem Fall). Befüllen Sie dieses Objekt in der Web-Schicht und behalten Sie es in der Sitzung, wenn Sie es brauchen. Auf diese Weise weiß Ihre Dienstschicht nichts über System.Web.

Answer 4

Nein. Dadurch wird es schwieriger, Ihren Code zu testen und wiederzuverwenden.

Ich neige dazu, eine Infrastrukturschnittstelle für diese Art von Sache zu bauen (nennen Sie es IAuthentication oder etwas) und eine CurrentUser-Eigenschaft auf sie freizugeben. Dann würde ich dies in meinen Dienst über seinen Konstruktor einfügen. d.h. public MyService(IAuthentication auth)

Schließlich können Sie eine HttpContext-bewusste Implementierung von IAuthentication (sagen wir WebAuthentication) erstellen.

Wenn Sie nun Ihren Dienst erstellen, erstellen Sie auch dessen Abhängigkeiten:

var myService = new MyService(new WebAuthentication());
var otherUsers = myService.GetAllOtherUsers();

Wenn Sie einen IoC-Container verwenden, kann die hässliche Abhängigkeit sogar verschwinden!