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

Question

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

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

Answer 1

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

• 您永远无法在ASP.NET
以外的任何地方使用业务层代码
• 单元测试变得更加痛苦甚至不可能。

当我们开始构建使用公共业务层代码的服务时，我们遇到了这种完全相同的情况。

Answer 2

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

Answer 3

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

Answer 4

创建一个间接的类，在这种情况下，它可以从HttpContext.Current.Session返回值，而在其他区域可以从其他地方解析它。 IE有一个接口ISessionStore，并具有WebSessionStore和WindowsFormsSessionStore等具体类。

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

Answer 5

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

很难将该业务层与环境分离。例如，如果你希望对这件事进行单元测试，那你就不幸了。

解决这个问题的一种方法就是将其绝对分散为现在的抽象，以便您可以传递“状态缓存”而不是引用HttpContext。这至少会带给你某种程度的抽象。 另一个更有趣的问题是，为什么业务层需要引用它？

Answer 6

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