Web应用程序架构 - 关于将 HTTPContext 保留在表示层中的建议
大多数应用程序架构建议似乎都强烈建议只有表示层才能访问 HTTPContext（以促进松散耦合、减少依赖性、提高可测试性等）。
那么，人们如何处理Caching和Session呢？需要非常具体的数据访问和业务逻辑知识来确定哪些项目需要缓存才能最大程度地提高应用程序性能。但是，对于 ASP.Net Web 应用程序，对这些内容的访问是通过 HTTPContext 提供的。
一种选择是创建一个 CacheFactory 和一个 SessionFactory，以及一个 ICache 和 ISession 接口 - 然后以某种方式使用 DI 原理将 ISession 和 ICache 传递给 BLL 中的每个方法以及随后需要它的 DA 层。
这真的是开发商最终要做的吗？还有另一种更简单的方法来处理这个问题吗？
感谢您的任何建议。
The majority of the Application Architecture advice seems to advise strongly that only Presentation Layer should have access to HTTPContext (to promote loose coupling, decrease dependencies, increase testability etc).
So, how do people deal with Caching and Session? Very specific DataAccess and Business Logic knowledge is required to determine what items need caching to best benefit application performance. However, and an ASP.Net web application, access to these is provided via the HTTPContext.
One option would be to create a CacheFactory and a SessionFactory, and an ICache and ISession interface - and then somehow use DI principle to pass and ISession and ICache to each method in the BLL and subsequently DA Layer that needs it.
Is this really what developers end up doing? Is there another, easier, way to deal with this?
Thanks for any advice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
就我个人而言，如果我仅针对 ASP.NET（Web）进行开发，并且我知道类库仅针对 Web，那么根据需要引用 System.Web 或任何其他程序集不会出现任何问题。有时实用性应该是第一位的。
另一方面，如果您知道或不确定 BLL、DAL 或其他层是否可以在客户端服务器或其他环境中重用，您可能需要考虑使用更灵活的方法，例如会话处理程序接口等 。
最主要的是您清楚地了解最佳实践的建议 那时，您可以就哪些内容适用于每个项目或情况做出理性的决定。它并不总是像手套一样合身。
Personally, if I'm developing for ASP.NET (web) only, and I know the class libraries are only going to target the web, I have no issues referencing System.Web or any other assembly as needed. Sometimes practicality should come first.
On the other hand if you know, or are unsure if the BLL, DAL or other layers may be reused in a client-server or other environment, you may need to look at using a more flexible approach such as a session handler interface, etc.
The main thing is you clearly understand what best practice recommends. At that point you can make rational decisions about what should apply to each project or situation. It won't always fit like a glove.
根据我的经验，缓存是在某个层完成的 - 并且您所缓存的内容适用于该层的范围内，因此：
当您查看缓存时，作为系统的架构师/设计者，您将做出决定关于哪些内容值得缓存，通常这是由平衡需求驱动的：
假设我们通过缓存来提高性能，您将需要分析您的系统并确定需要消除或避免的瓶颈 - 此分析的第一遍应该至少确定首先关注哪一层。
另一件需要考虑的事情是，您可以缓存的内容越靠近消费者，需要进行的整体处理就越少；换句话说，如果您可以在 UI 层进行缓存，那么 BL 和 DAL 层甚至不会被查看（您不需要在那里添加缓存）。
此时我想问你到底想要实现什么目标。
虽然我所说的一切都是正确的（据我所知），但这一切都基于这样的假设：我们正在提供系统功能的“垂直”部分（例如“创建发票”、“添加产品”等） ;您可以应用另一种模型 - 横切关注点模型。
考虑像日志记录这样的事情 - 系统的每个部分（UI / BL / DAL）都应该能够记录系统事件；我最喜欢的工具是 MS Enterprise Libraries (MSEntLibs)。当我与他们一起工作时，我认为他们是一个“黑匣子”——一个独立的单元。我（自愿）不知道它们是如何构建的 - 重要的是它们是隔离的并且具有相对易于管理的依赖关系。
MSEntLibs 可以登录到数据库，但如果我直接从 UI 调用 MSEntLibs 日志记录方法（登录到数据库）（并跳过我的 BL），我不在乎。
因此，根据您尝试执行的操作，正确的答案将是：
In my experience caching is done ata certain layer - and what you're caching applies within the scope of that layer, so:
When you look at caching, as the architect / designer of the system you'll make decisions about what things are worth caching, generally this will be driven by a need to balance:
Assuming we're caching to increase performance, you'll want to analyse your system and identify the bottlenecks that need to be removed or avoided - the first pass of this analysis should at least identify which layer to focus on first.
Another thing to consider is that the more you can cache closer to the consumer - the less overall processing there is that needs to occur; in otherwords, if you can cache at the UI layer then the BL and DAL layers won't even get a look-in (you won't need to add caching there).
At this point I want to ask you what exactly it is that you're trying to achieve.
While everything I've said is true (as far as I am aware) it's all based on the assumption that we're delivering "vertical" slices of the systems functionality (like "creating an invoice", "adding a product" etc); there's another model you can apply - the cross-cutting concerns model.
Think about something like logging - every part of you system (UI / BL / DAL) should be able to log system events; my favourite tool for this is the MS Enterprise Libraries (MSEntLibs). When I work with them I consider them to be a "black-box" - a self contained unit. I (by choice) have no idea how they are architected - the thing that is important is that they are isolated and have dependencies which are relativly easy to manage.
The MSEntLibs can log to a database, but if I call an MSEntLibs logging method (to log to the DB) direct from my UI (and skipping over my BL) I don't care.
So depending on what you're trying to do the right anmswer will either be: