在单独的帮助程序类中访问控制器外部的 HttpContext 会话的最佳实践

Question

在单独的帮助程序类中访问控制器外部的 HttpContext 会话是一个好习惯吗？

====================

控制器是否应该承担从会话获取数据并将其传输到辅助类

示例

HomeController : BaseController
{
    var value1 = Httpcontext.Session["key1"];
    var value2 = Httpcontext.Session["key2"];
    var val...
    CallAMethod(value1,value2,val...);
}

的所有责任，或者是否应该模拟 HttpContextBase 并将其用作在下面？

HomeController : BaseController
{
    //Use Dependency Injection pattern
    CallAMethod(base.SessionWrapper);
}

ISessionWrapper 的实现是

public interface ISessionWrapper
{
     T GetFromSession<T>(string key);
     SetInSession(string key, object value);
}

public class HttpContextSessionWrapper : ISessionWrapper
{
   private T GetFromSession<T>(string key)
   {
      return (T) HttpContext.Session[key];
   }

   private void SetInSession(string key, object value)
   {
      HttpContext.Session[key] = value;
   }
}

public class BaseController : Controller
{
   public ISessionWrapper SessionWrapper { get; set; }

   public BaseController()
   {
      SessionWrapper = new HttpContextSessionWrapper();
   }
}

Answer 1

显然，您希望代码具有一定的可测试性（毕竟这就是您要承受创建 ISessionWrapper 负担的原因）。

两种方法都有优点和缺点。

---

• 直接使用HttpContext

  • 开发速度更快

  • 需要一些关于测试类的想法。还需要模拟 HttpContext 的能力。可以使用 NET 上提供的库。

---

• 使用依赖注入（ISessionWrapper）：

  • 开发速度较慢

  • 需要在访问 HttpContext 方面“重新发明轮子”

  • 需要编写和维护更多代码

---

因此，我会考虑这两种方法的优缺点，并根据我的目标做出决定。

然而，就我个人而言，我会选择需要编写的代码少得多的路径。

---

编辑添加

为了回答问题的核心（在OP的唠叨之后），控制器应该始终管理数据收集，然后再将它们传递给执行器。