0

大多数应用程序架构建议似乎都强烈建议只有表示层才能访问 HTTPContext（以促进松散耦合、减少依赖关系、增加可测试性等）。

那么，人们是如何处理 Caching 和 Session 的呢？需要非常具体的数据访问和业务逻辑知识来确定哪些项目需要缓存以最大程度地提高应用程序性能。但是，对于 ASP.Net Web 应用程序，对这些的访问是通过 HTTPContext 提供的。

一种选择是创建一个 CacheFactory 和一个 SessionFactory，以及一个 ICache 和 ISession 接口 - 然后以某种方式使用 DI 原理将 ISession 和 ICache 传递给 BLL 中的每个方法，然后是需要它的 DA 层。

这真的是开发人员最终要做的吗？还有另一种更简单的方法来处理这个问题吗？

感谢您的任何建议。

4

2 回答 2

1

就个人而言，如果我只为 ASP.NET (web) 进行开发，并且我知道类库只针对 web，那么我可以根据需要引用 System.Web 或任何其他程序集。有时实用性应该是第一位的。

另一方面，如果您知道或不确定 BLL、DAL 或其他层是否可以在客户端服务器或其他环境中重用，您可能需要考虑使用更灵活的方法，例如会话处理程序接口等.

最重要的是您清楚地了解最佳实践的建议。那时，您可以对每个项目或情况适用的内容做出合理的决定。它并不总是像手套一样合身。

于 2010-09-02T17:27:29.527 回答
0

以我的经验，缓存是在某个层完成的 - 您正在缓存的内容适用于该层的范围，因此：

  • 您可以在 DAL 中缓存数据，以便 DAL 从内存中返回数据，而不是再次访问数据库；所以在这里我们在数据级别缓存“原始”数据。
  • BL 可能会缓存类似的数据（比如 POCO）——换句话说，已经应用了 BL 的“逻辑”数据；所以这里我们在 BL 级别缓存 BL 数据。
  • 您的 UI 可能会缓存（您猜对了）在 UI 层构建的信息——例如将数据表示为网页、XML 等。

当您查看缓存时，作为系统的架构师/设计师，您将决定哪些东西值得缓存，通常这将由平衡需求驱动：

  • 性能需要达到特定目标。
  • 您有什么时间（和成本）选项。

假设我们正在缓存以提高性能，您将需要分析您的系统并确定需要消除或避免的瓶颈 - 此分析的第一遍至少应该确定首先关注哪一层。

要考虑的另一件事是，您可以在更靠近消费者的地方缓存更多 - 需要进行的整体处理就越少；换句话说，如果你可以在 UI 层缓存，那么 BL 和 DAL 层甚至都不会被查看（你不需要在那里添加缓存）。

在这一点上，我想问你，你想要达到的究竟是什么。

虽然我所说的一切都是真实的（据我所知），但这一切都是基于我们正在提供系统功能的“垂直”切片的假设（如“创建发票”、“添加产品”等） ; 您可以应用另一种模型——横切关注点模型。

想想像日志这样的东西——系统的每个部分（UI / BL / DAL）都应该能够记录系统事件；我最喜欢的工具是 MS Enterprise Libraries (MSEntLibs)。当我和他们一起工作时，我认为他们是一个“黑匣子”——一个独立的单元。我（通过选择）不知道它们是如何构建的——重要的是它们是孤立的并且具有相对容易管理的依赖关系。

MSEntLibs 可以记录到数据库，但如果我直接从我的 UI 调用 MSEntLibs 记录方法（记录到数据库）（并跳过我的 BL），我不在乎。

因此，根据您要执行的操作，正确的答案将是：

  • 只需确定需要缓存的内容，让适当的层处理它。
  • 您根本不需要尝试使用 DI 将东西传递给您的 BL - 横切黑盒组件可能合适吗？
于 2010-09-02T22:18:33.910 回答