大多数应用程序架构建议似乎强烈建议只有表示层才能访问HTTPContext（以促进松散耦合，减少依赖性，提高可测试性等）。
那么，人们如何处理缓存和会话？需要非常具体的DataAccess和业务逻辑知识来确定哪些项目需要缓存以最大程度地提高应用程序性能。但是，和ASP.Net Web应用程序一样，通过HTTPContext提供对这些应用程序的访问。
一个选项是创建一个CacheFactory和一个SessionFactory，以及一个ICache和ISession接口 - 然后以某种方式使用DI原理将传递和ISession和ICache传递给BLL中的每个方法以及随后需要它的DA层。
这真的是开发人员最终做的吗？是否还有另一种更容易处理的方法？
感谢您的任何建议。
答案 0 :(得分：1)
就个人而言，如果我只针对ASP.NET（web）进行开发，并且我知道类库只是针对Web，那么我根本不需要引用System.Web或任何其他程序集。有时应该先实用性。
另一方面，如果您知道或不确定BLL，DAL或其他层是否可以在客户端 - 服务器或其他环境中重用，您可能需要使用更灵活的方法，例如会话处理程序界面等。
主要的是你清楚地了解最佳实践建议。此时，您可以就每个项目或情况应适用的内容做出合理的决定。它并不总是像手套一样。
答案 1 :(得分：0)
根据我的经验，缓存是在某个层完成的 - 您正在缓存的内容适用于该层的范围，因此：
当你看到缓存时，作为系统的架构师/设计师，你将决定哪些东西值得缓存，通常这需要平衡：
假设我们正在缓存以提高性能，您需要分析系统并确定需要删除或避免的瓶颈 - 此分析的第一步应该至少确定首先关注哪个层。 / p>
要考虑的另一件事是，您可以越靠近消费者进行缓存 - 需要发生的整体处理越少;换句话说，如果你可以在UI层缓存，那么BL和DAL层甚至都不会看到（你不需要在那里添加缓存）。
此时我想问你到底想要达到的目的是什么。
虽然我所说的一切都是真的（据我所知），但这都是基于我们正在提供系统功能的“垂直”切片的假设（如“创建发票”，“添加产品”） “等）;还有另一种可以应用的模型 - 横切关注模型。
考虑记录等事情 - 系统的每个部分（UI / BL / DAL）都应该能够记录系统事件;我最喜欢的工具是MS企业库（MSEntLibs）。当我与他们合作时，我认为他们是一个“黑盒子” - 一个独立的单位。我（选择）不知道它们是如何构建的 - 重要的是它们是孤立的并且具有相对易于管理的依赖性。
MSEntLibs可以登录到数据库，但如果我直接从我的UI调用MSEntLibs日志记录方法（登录到数据库）（并跳过我的BL），我不在乎。
因此，根据您正在尝试做的事情，正确的答案将是：