为什么Microsoft警告使用PerRequestLifetimeManager [英] Why does Microsoft warn from using PerRequestLifetimeManager
问题描述
尽管PerRequestLifetimeManager生命周期管理器正常工作，可以帮助在HTTP请求的范围内使用有状态或线程不安全的依赖关系，但通常不是一个好主意使用它可以避免，因为它常常导致不良做法或难以找到最终用户的应用程序代码错误使用错误。建议您注册的依赖关系是无状态的，并且如果在HTTP请求的生存期内需要在多个对象之间共享公共状态，则可以使用无状态服务使用当前对象。
Although the PerRequestLifetimeManager lifetime manager works correctly and can help in working with stateful or thread-unsafe dependencies within the scope of an HTTP request, it is generally not a good idea to use it when it can be avoided, as it can often lead to bad practices or hard to find bugs in the end-user's application code when used incorrectly. It is recommended that the dependencies you register are stateless and if there is a need to share common state between several objects during the lifetime of an HTTP request, then you can have a stateless service that explicitly stores and retrieves this state using the Items collection of the Current object.
警告引用了什么样的错误或不良做法？怎么会错误地使用它？ - 不幸的是，警告并不是很具体，因此很难适用于现实世界。此外，在这种情况下，我不清楚什么是有状态的意思。
What kind of bugs or bad practices is the warning refering to? How would one use it incorrectly? - Unfortunately the warning is not very specific and is therefore hard to apply to the real world. Furthermore it is not clear to me what stateful means in this context.
IMHO使用PerRequestLifetimeManager的典型场景将是某种数据库连接（例如DbContext）或类似的
IMHO a typical scenario to use the PerRequestLifetimeManager would be some kind of database connection (e.g. DbContext) or similiar.
推荐答案
其目的是仅实例化每个请求的一个实例，这可以（例如）阻止冗余操作和查找一个请求的过程。
Its purpose would be to only instantiate one instance per request, which could (for example) prevent redundant operations and lookups during the course of a single request.
危险是，如果有人认为创建的对象是在请求期间存储状态的好地方。依赖注入的想法是，类接收依赖（通常是接口），并且除了它实现该接口之外，并不知道任何关于它的东西。
The danger is if someone assumes that the object created is a good place to store state during the request. The idea of dependency injection is that a class receives a dependency (commonly an interface) and doesn't "know" anything about it at all except that it implements that interface.
但有人可能会认为，如果对象在请求的整个生命周期中都会持续存在，那么在请求期间维护状态就是一个好地方。所以他们创建一个复杂的场景，其中一个类接收依赖项，在其中存储一些信息（如设置一个属性），然后另一个类接收到相同的依赖关系，并期望读取该属性。
But someone could reason that if the object is going to persist throughout the life of the request then it's a good place to maintain state during the request. So they create a complex scenario where one class receives the dependency, stores some information in it (like setting a property), and then another class receives that same dependency and expects to read that property.
现在，依赖注入（去耦）的目的已经被打败了，因为类内置了关于该依赖关系的生命周期的假设，甚至可以包括关于什么其他类对该对象的状态已经完成或将执行。这造成了一个混乱的混乱，类之间的互动难以察觉 - 甚至隐藏 - 所以很容易破坏。
Now the purpose of dependency injection (decoupling) has been defeated because classes have built-in assumptions about what the lifetime of that dependency is, and may even include assumptions about what other classes have done or will do with the state of that object. That creates a tangled mess where the interaction between classes is difficult to perceive - even hidden - and so it's easy to break.
让我们来说有人认为这种依赖的生活方式应该是短暂的，而不是每个web请求。突然间依赖于这些类的所有行为都会按预期的方式停止工作。所以开发人员看这些类，看看没有变化。发生了什么？这些课程之间的相互作用很难看出，所以当它打破问题时，很难找到。如果有一个有效的理由为什么依赖关系的生活方式改变了，那么问题将更难修复。
Let's say someone determines that the lifestyle of that dependency should be transient, not per web request. Suddenly all of the behaviors of those classes that depend on it stop working as expected. So developers look at those classes and see that nothing has changed. What happened? The interaction between those classes was hard to see in the first place, so when it breaks the problem will be hard to find. And if there was some valid reason why the lifestyle of that dependency was changed then the problem is going to be even harder to fix.
如果我们需要在请求，那么我们应该把它放在正常的地方，比如在 HttpContext 中。仍然有一些令人困惑的做法和错误的空间，但是至少我们知道，根据定义， HttpContext 将被绑定到一个特定的请求。
If we need to store state during a request then we should put it in "normal" places like in the HttpContext. There's still room there for some confusing practices and bugs, but at least we know that the HttpContext is (by definition) going to be tied to a particular request.
这篇关于为什么Microsoft警告使用PerRequestLifetimeManager的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
