Castle Windsor组件依赖关系和生活方式

Question

我想知道Castle Windsor组件依赖生活方式的最佳实践是什么。例如，如果我有一个依赖于ISession的Repository类。如果存储库设置为PerWebRequest，但ISession设置为瞬态，这是否会对windsor释放组件以使GC能够正确清理造成任何问题？

从逻辑上讲，这似乎是可行的，因为在webrequest过程中，每个对Repository的请求都将获得对同一实例的引用。该实例将持有对单个ISession的引用，该实例在第一次被请求时被实例化以满足回购依赖关系。温莎将知道回购何时由于PerWebRequest跟踪而超出范围，因此应该知道何时清理ISession。

然而，Krzysztof Koźmic的this post暗示，你不应该有一个依赖于生活方式比它本身更短的组件。

编辑

我的问题是，让Windsor组件依赖于比它本身更短的生活方式(即PerWebRequest组件->瞬态组件)，这是可以接受的吗？

Answer 1

是的，它可以非常好，特别是在something --> transient的情况下。你需要担心的事情是：

• 我是否强制这个组件存在(并停留在内存中)的时间比它应该存在的时间更长？
• 我不会在我所依赖的对象被自动释放的情况下结束(就像依赖于每个web请求的单个对象的情况，该对象在第一个web请求结束时被释放)。在这种情况下，您最终将使用处于无效状态的对象，这取决于您如何实现它，要么抛出异常(快速失败)，要么行为不检(您不希望出现这种情况)。

如果您已经考虑了这两个因素，并且可能还有其他一些特定于您的场景的因素，那么您就处于一个很好的位置，可以做出明智的选择来推动依赖关系的发展。

或者，您可以通过间接层使其成为可传递的依赖关系：

singleton -(depends on)-> singleton factory -(resolves)-> per-web-request component。

单例对象可能依赖于它用来拉取的工厂，比方说，它用来执行其工作的每个web请求的对象。有了它，如果实现得当，它就不会有上面讨论的缺点。

希望这能有所帮助。

哦，还有我的另一个答案，你在你的问题中链接到-它说的是经验法则，而不是严格的法律。在大多数情况下，它可能是正确的，但是，正如上面所讨论的，如果您知道自己在做什么，那么打破它是很好的。这也是为什么Windsor用于检测这些情况的诊断程序被称为潜在错误配置组件的原因

Answer 2

为什么你会在一个web请求中有多个会话。关于会话，我在web应用程序中常用的一种模式是Unit of Work模式。其中web请求是工作单元。

Answer 3

短暂的生活方式只有当你显式地释放它或它的父级时才会释放。因此，拥有一个短暂的组件，它是每个web请求生活方式的组件的依赖项，应该是很好的。