Castle Windsor组件依赖和生活方式

Question

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

从逻辑上讲，这似乎可行，因为在webrequest期间对存储库的每次请求都将获得对同一实例的引用。该实例将保留对单个ISession的引用，该ISession在首次请求时实例化以满足Repo依赖性。由于PerWebRequest跟踪，Windsor将知道Repo何时超出范围，因此应该知道何时清理ISession。

然而，KrzysztofKoźmic的this post暗示你不应该让一个组件依赖于生活方式比自己更短的东西。

[编辑]

我的问题是，让温莎组件依赖于生活方式比自身更短的东西（即PerWebRequest组件 - ＆gt;瞬态组件）是否可以接受？

Answer 1

是的，它可以完全没问题，尤其是在something --> transient的情况下。你需要担心的是：

• 我是否强迫这个组件存活（并留在内存中）比它应该更长？
• am我不会在我依赖的对象被自动释放的情况下结束（例如，单个依赖于每个Web请求对象的单例，在第一个Web请求结束时释放） 。在这种情况下，您将最终使用处于无效状态的对象，这取决于您实现它的方式将抛出异常（快速失败）或行为异常（您不希望在那里）。

如果您已经考虑了这两个因素，并且可能还有一些特定于您的场景的其他因素，那么您就可以做出明智的选择，继续使用依赖关系。

或者你可以通过一个间接层使它成为传递依赖：

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

单例对象可能依赖于工厂，它用于拉动（例如）用于执行其工作的每个Web请求对象。有了这个，如果实施得当，它将没有上面讨论的缺点。

希望有所帮助。

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

Answer 2

为什么您会在一个网络请求中拥有多个会话。我常用于关于会话的Web应用程序的一种模式是工作单元模式。 Web请求是工作单元的地方。

Answer 3

瞬态生活方式仅在您明确释放或其父母时释放。因此，拥有一个瞬态组件是一个依赖于具有每个Web请求生活方式的组件应该没问题。