IOC 容器和 Web 应用程序
我已经开始研究这个 .NET Web 应用程序，它有一个 IOC 容器（Windsor）来创建业务管理器，并将它们保存在内存中，直到 IIS 回收它们。基本上，这些业务管理器拥有自己的状态和数据，其内容是从在 Application_Start 触发的后台线程修改的。这不是我期望的 Web 应用程序的工作方式（它应该是无状态的，并且每个请求的每个线程），而且我不太确定这个实现是否可持续/可扩展。有没有人尝试过这种方式，如果是的话，您从中看到的后果/优点是什么？
I have started to work on this .NET web application where it has an IOC container (Windsor) to create business managers, and to keep them in the memory until the IIS recycles them. Basically these business managers are having their own states, and data of which the content is modified from background threads that are fired at the Application_Start . This is not the way I was expecting an web application to work ( which are supposed to be stateless and per thread for per request) and I'm not quite sure if this implementation is sustainable/scalable. Has anybody tried the things in this manner if so what are the consequences/pros that you see in this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们在应用程序中使用静态，仅用于核心功能。静态类在所有请求之间共享，因此可用性应该有点低。在开发领域，我们看到静态越来越多地出现：ASP.NET MVC 3 将它们用于应用程序的各个领域，以及其他流行的操作系统源库。
只要它们不是很多，就应该没问题......但您始终可以使用内存分析器进行验证，看看它们有多大，以及它们是否占用了太多内存。
另一种选择是将它们放置在缓存中，或者重建它们并将它们存储在每个请求中。要将它们全局存储在请求中，请使用 HttpContext.Current.Items 集合。
We use statics in the application, only for the core features. Static classes are shared across all the requests, so usability should be somewhat low. In the development world, we're seeing statics pop up more and more: ASP.NET MVC 3 utilizes them for various areas of the application, as well as other popular OS source libraries.
As long as there aren't a lot of them, you should be OK... but you can always verify with a memory profiler too see how big they are getting, and whether they are sucking up too much memory.
The other alternative could be to place them in cache, or rebuild them and store them in each request. To store them globally in a request, use
HttpContext.Current.Itemscollection.