在Map中注入时,StructureMap会警告 - 为什么？

Question

在关于生命周期的StructureMap文档中,他们声明一个作用域选项是HttpSession,并且它:"将实例缓存在HttpContext.Session集合中.请谨慎使用."

我不知道要小心谨慎,而且我的google-fu让我失望了.

我们使用的用例是我们要缓存一些昂贵的Web服务调用.其中一些是无国籍的,但其中一些与特定用户有关.

如果我们注入会话范围,我们什么时候不好,顽皮的人？我们需要防范什么？

Answer 1

我会用一个极端的例子,缓存工作对象的单位(如LINQ to SQL中的描述与此问题DataContext,实体框架的ObjectContext或者DbContext或NHibernate的ISession):

内存占用

工作单元对象通常会保留大量对象.将会话对象放在HttpSession中意味着它会在会话存在的时间内存在,并且与缓存中的所有对象一起存在.即使用户在20分钟后回来,您的应用程序也会受到此内存压力.这可能(并且在相当大的负载下)会导致内存不足异常.

数据变得陈旧

由于工作单元对象缓存从数据库加载的所有实体,因此该数据会很快变得陈旧.当数据被另一个用户更改时,默认情况下不会刷新缓存的数据,并且您可能会遇到奇怪的行为,其中一个用户看到一些数据,但另一个用户看到其他数据.刷新页面将不起作用,因为您在会话的生命周期内缓存了数据.只关闭浏览器才有效(有时).

序列化

当您将Web服务器扩展(这意味着您添加更多服务器)时,会话信息必须从一个服务器传输到另一个服务器.您将必须使用进程外缓存(例如MemCache或SQL Server).工作单元对象很难或不可能序列化和反序列化,这意味着如果您需要或不需要,则无法扩展.

摘要

这个例子是极端的,因为你不应该在工作单元模式上使用每个会话的生活方式.但它仍然相当清楚地描述了这个问题.每个会话的生活方式增加了应用程序的内存占用,因为服务保持很长时间.如果您使用此类服务​​来缓存数据,它可能会变得陈旧(尽管缓存可能只是提高性能所需的).尽管DTO通常易于序列化,但这并不适用于您注册的任何服务.这意味着您无法向外扩展,因为可序列化的会话对象需要向外扩展.

因此,不要在服务上使用Per Session生活方式,而是尝试构建无状态服务,以便将它们注册为singleton.可以从HTTP会话请求他们需要的任何用户特定数据.