网站的业务层是否应该访问会话状态？答案

【问题标题】：Should a web site's business layer access the session state?网站的业务层是否应该访问会话状态？
【发布时间】：2009-04-24 14:09:08
【问题描述】：

我正在维护一个 ASP.NET 网站，我注意到业务层和其他支持库大量使用 HttpContext.Current.Session。这使得跟踪会话变量、确定它们的用途以及它们存在的原因变得困难。

在业务层使用会话是否被认为是不好的做法？开始将所有使用会话的代码移动到代码隐藏中是否明智？

【问题讨论】：

【解决方案1】：

这几乎不是一个好主意。有很多原因，但这里有几个：

当我们开始构建使用通用业务层代码的服务时，我们遇到了与这种完全相同的情况非常头疼的问题。

【讨论】：

【解决方案2】：

我遵循这条规则 - System.Web 命名空间（Java 中的 javax.servlet 包）中的任何类都不应该出现在您的业务层中。

【讨论】：

【解决方案3】：

是的 - BL 不应该对会话有任何了解。它是您不需要的依赖项。

【讨论】：

【解决方案4】：

创建一个间接类，在这种情况下，在网络上它可能会从 HttpContext.Current.Session 返回值，而在其他领域会从其他地方解决这个问题。 IE有ISessionStore接口，有WebSessionStore、WindowsFormsSessionStore等具体类

这将使您的代码更容易测试，并为您提供扩展路径，例如，您现在希望 x 业务逻辑在 Windows 服务中运行，它可以每 y 分钟运行 x 段代码。

【讨论】：

【解决方案5】：

在我看来这是不好的做法。

很难将该业务层与环境分离。例如，如果您希望对事物进行单元测试，那么您就不走运了。

解决这个问题的一种方法是暂时将其隔离为抽象，这样您就可以传递“状态缓存”而不是引用 HttpContext。这至少会让你达到某种程度的抽象。另一个更有趣的问题是，为什么业务层需要引用它？

【讨论】：

这是关于单元测试的一个好点。至于为什么业务层需要HttpContext：登录用户的信息，比如他们的角色和权限，都保存在会话中，这会影响业务逻辑的作用。我会尝试抽象出状态并传递它——这听起来是一个很好的解决方案。
问题在于“当前用户”是一个普遍的概念，您将通过不需要它的对象层来携带它。听起来是使用 IOC 的一个很好的理由，但这是一个完全不同的球类游戏，而不是简单的修改......

【解决方案6】：

最好有一个集中的缓存/会话管理器，它封装了与会话/缓存或您使用的任何持久性方法的完整交互。让你的 BL 与会话进行交互绝对是一种非常糟糕的做法，并且在某种程度上完全违背了分层架构的目的。

【讨论】：