Asp.net WebApplication架构-关于在表示层中保留HTTPContext的建议

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

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

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

这真的是开发者最终要做的吗？有没有其他更简单的方法来处理这个问题

---

谢谢你的建议。

就我个人而言，如果我只为ASP.NET（web）开发，而且我知道类库只针对web，那么我在引用System.web或任何其他需要的程序集时不会遇到任何问题。有时实用性应该放在第一位

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

---

最重要的是，您清楚地了解最佳实践的建议。在这一点上，您可以对每个项目或情况应用什么做出理性的决定。它并不总是像手套一样合身。

根据我的经验，缓存是在某个层上完成的，并且缓存的内容适用于该层的范围，因此：

• 您可以在DAL中缓存数据，以便DAL从内存返回数据，而不是再次命中DB；所以这里我们在数据级别缓存“原始”数据
• BL可能缓存类似的数据（比如POCO的数据）——换句话说，BL应用于它的“逻辑”数据；所以这里我们在BL级别缓存BL数据
• 您的UI可能会缓存（您猜到了）在UI层构建的信息，即以网页、XML等形式表示的数据

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

• 性能需要达到特定的目标
• 你有什么时间（和成本）选择

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

另一个要考虑的是，你可以越接近消费者的缓存，就越不需要进行全面的处理；换句话说，如果您可以在UI层缓存，那么BL和DAL层甚至不会查看（您不需要在那里添加缓存）

在这一点上，我想问你，你到底想要实现什么

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

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

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

因此，根据您的努力，正确的anmswer将是：

• 只需确定需要缓存什么，就可以让适当的层处理它
• 您根本不需要尝试使用DI将内容传递给BL—一个横切的黑盒组件可能是合适的