在StructureMap documentation on life cycle中，他们声明一个作用域选项是HttpSession，并且：“将实例缓存在HttpContext.Session集合中。请谨慎使用。”
我不知道要小心谨慎，而且我的google-fu让我失望。
我们使用的用例是我们要缓存一些昂贵的Web服务调用。其中一些是无国籍的，但其中一些与特定用户有关。
如果我们注入会话范围，我们什么时候不好，顽皮的人？我们需要防范什么？
答案 0 :(得分：11)
我将通过一个极端的例子来描述这个问题，缓存一个工作单元对象（例如LINQ to SQL的DataContext，实体框架的ObjectContext或DbContext或NHibernate的ISession）：
内存占用
工作单元对象通常会占用大量对象。将会话对象放在HttpSession中意味着它会在会话存在的时间内存在，并且与缓存中的所有对象一起存在。即使用户在20分钟后回来，您的应用程序也会受到此内存压力。这可能（并且在相当大的负载下）会导致内存不足异常。
数据变得陈旧
由于工作单元对象缓存从数据库加载的所有实体，因此该数据会变得过时。当数据被另一个用户更改时，默认情况下不会刷新缓存的数据，并且您可能会遇到奇怪的行为，其中一个用户看到一些数据，但另一个用户看到其他数据。刷新页面将不起作用，因为您在会话的生命周期内缓存了数据。只有关闭浏览器才能工作（有时）。
<强>序列化
当您将Web服务器扩展（这意味着您添加更多服务器）时，会话信息必须从一台服务器传输到另一台服务器。您将必须使用进程外缓存（例如MemCache或SQL Server）。工作单元对象很难或不可能序列化和反序列化，这意味着如果您需要或不需要，则无法扩展。
<强>摘要
这个例子是极端的，因为你不应该在工作单元模式上使用每个会话的生活方式。但它仍然相当清楚地描述了这个问题。每个会话的生活方式增加了应用程序的内存占用，因为服务保持很长时间。如果您使用此类服务来缓存数据，它可能会变得陈旧（尽管缓存可能只是提高性能所需的）。尽管DTO通常易于序列化，但这并不适用于您注册的任何服务。这意味着您无法向外扩展，因为可序列化的会话对象需要向外扩展。
因此，不要在服务上使用Per Session生活方式，而是尝试构建无状态服务，以便将它们注册为singleton。可以从HTTP会话中请求他们需要的任何用户特定数据。