【问题标题】:HttpApplicationState outside of the Web Project (Class Library)Web 项目(类库)之外的 HttpApplicationState
【发布时间】:2013-07-19 18:01:02
【问题描述】:

我有一个 ASP.net Web 应用程序,它的业务逻辑依赖于一个单独的 DLL 类库项目。但是,我想在 DLL 项目中使用全局 HttpApplicationState。但这似乎是一个特定于 Web 项目的实现。

当然,我可以让特定类的构造函数(或方法)将 HttpApplicationState 作为参数,但我想知道是否有更雄辩的方式来做到这一点。我意识到我正在制造一些设计问题,但我真的很希望能够在我的业务逻辑中使用全球性的东西。

【问题讨论】:

    标签: asp.net httpapplicationstate


    【解决方案1】:

    使用HttpContext.Current.Application,您应该能够在外部类中访问 HttpApplicationState。

    更新

    但我同意 John Saunders 的观​​点 - 业务逻辑不应该知道它是从哪里调用的。

    【讨论】:

      【解决方案2】:

      您应该尝试将 Web 应用程序和类库之间的关注点分开。类库应该尽可能少地了解 Web 应用程序正在调用它们的事实。特别是,它们不应该使用会话状态或应用程序状态。事实上,它们最好不要引用 System.Web.dll!

      让 Web 应用程序将类库所需的应用程序状态片段传递给类库。类库应该不知道数据来自应用程序状态这一事实。

      这也将使类库的单元测试变得更加容易,因为可以从单元测试框架中调用它。

      【讨论】:

      • 我正在寻找实现一个对象池模式,并且真的希望依靠应用程序状态来实现它的一些机械化......我想保持和重用页面之间的数据库连接。目前,我的业务逻辑对象初始化数据库连接,并且随着客户端从一个页面到另一个页面,这些连接被重新初始化,这会产生一些问题。所以,理想情况下,我希望我的 BLL 能够使用某种池来防止这些连接被 GC 删除。我可以使用另一种模式来完成此操作吗?
      • 问题不在于模式 - 在于持久性存储。为什么不直接使用static 数据(带有适当的锁定)来存储对象。此外,大多数数据库客户端都有连接池,因此您甚至可能不需要自己做。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多