我想知道 CaSTLe Windsor 组件依赖生活方式的最佳实践是什么。例如，如果我有一个依赖于 ISession 的存储库类。如果 Repository 设置为 PerWebRequest，但 ISession 设置为 transient ，这是否会对 Windsor 释放组件造成任何问题，以便 GC 可以正确清理？
从逻辑上讲，这似乎可行，因为在 webrequest 期间对存储库的每个请求都将获得对同一实例的引用。该实例将保存对单个 ISession 的引用，该 ISession 在第一次被请求时被实例化以满足 Repo 依赖项。 Windsor 将知道 Repo 何时由于 PerWebRequest 跟踪而超出范围，因此应该知道何时清理 ISession。
但是，this post作者 Krzysztof Koźmic 暗示您不应该有一个组件依赖于生活方式比它本身更短的东西。
[编辑]
我的问题是，是否可以让 Windsor 组件依赖于生命周期比自身短的东西(即 PerWebRequest 组件 -> transient 组件)？
最佳答案
是的，它可以非常好，尤其是在 something --> transient 的情况下。您需要担心的是:
- 我是否强制此组件的生存时间(并保留在内存中)比应有的时间更长？
- 我不会最终遇到我所依赖的对象被自动释放的情况(比如一个依赖于每个 web 请求对象的单例，该对象在第一个 web 请求结束时被释放) .在这种情况下，您最终会使用处于无效状态的对象，这取决于您的实现方式，它会引发异常(快速失败)或行为不端(您不想在那里)。
如果您已经考虑了这两个因素，以及可能针对您的场景的许多其他因素，那么您就可以做出明智的选择来继续处理依赖关系。
或者，您可以通过间接层使其成为传递依赖:
singleton -(取决于)-> singleton factory -(resolves)-> per-web-request 组件。
一个单例对象可能依赖于一个工厂，该工厂用于拉取(例如，用于完成其工作的每个网络请求的对象)。这样一来，如果实现得当，它就不会有上面讨论的缺点。
希望对您有所帮助。
哦，我的另一个答案，你在你的问题中链接到 - 它说 经验法则，而不是严格的法律。在大多数情况下它可能是正确的，但是，如上所述，如果您知道自己在做什么，就可以打破它。这也是温莎检测这些案例的诊断被称为可能配置错误的组件
的原因关于asp.net-mvc-3 - CaSTLe Windsor 组件依赖性和生活方式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6791323/