为什么Microsoft警告不要使用PerRequestLifetimeManager
本文关键字：PerRequestLifetimeManager Microsoft 警告 为什么 | 更新日期: 2023-09-27 17:57:33
https://msdn.microsoft.com/en-us/library/microsoft.practices.unity.perrequestlifetimemanager（v=pandp.30）.aspx声明：
尽管PerRequestLifetimeManager生存期管理器工作正常，并且可以帮助处理HTTP请求范围内的有状态或线程不安全依赖项，但在可以避免的情况下使用它通常不是一个好主意，因为如果使用不正确，它通常会导致不良做法或在最终用户的应用程序代码中很难找到错误。建议您注册的依赖项是无状态的，如果在HTTP请求的生存期内需要在多个对象之间共享公共状态，则可以使用Current对象的Items集合来显式存储和检索此状态的无状态服务。
警告指的是什么样的错误或不良做法？怎么会用错呢？-不幸的是，这个警告不是很具体，因此很难应用于现实世界。此外，我还不清楚有状态在这种情况下意味着什么。
IMHO使用PerRequestLifetimeManager的典型场景是某种数据库连接（例如DbContext）或类似的连接。
它的目的是每个请求只实例化一个实例，这可以（例如）防止在单个请求过程中进行冗余操作和查找。
危险在于，如果有人认为创建的对象是在请求期间存储状态的好地方。依赖项注入的思想是，一个类接收一个依赖项（通常是一个接口），除了实现该接口之外，对它一无所知。
但有人可能会认为，如果对象将在请求的整个生命周期中持续存在，那么它是在请求期间保持状态的好地方。因此，他们创建了一个复杂的场景，其中一个类接收依赖项，在其中存储一些信息（如设置属性），然后另一个类收到相同的依赖项并期望读取该属性。
现在，依赖注入（解耦）的目的已经失败了，因为类有关于该依赖的生存期的内置假设，甚至可能包括关于其他类已经或将要对该对象的状态做什么的假设。这就造成了一个混乱的局面，类之间的交互很难感知，甚至是隐藏的，因此很容易破坏。
假设有人确定这种依赖的生活方式应该是短暂的，而不是每个web请求。突然间，那些依赖它的类的所有行为都像预期的那样停止了工作。因此，开发人员查看了这些类，发现没有任何变化。发生了什么？这些类之间的交互在一开始就很难看到，所以当它打破问题时，就很难找到。如果这种依赖的生活方式发生了改变，有什么合理的原因，那么这个问题将更难解决。
如果我们需要在请求期间存储状态，那么我们应该将其放在"正常"位置，如HttpContext中。仍然存在一些令人困惑的实践和错误，但至少我们知道HttpContext（根据定义）将与特定请求绑定。