城堡溫莎組件依賴關係和生活方式

Question

我想知道什麼是城堡溫莎組件依賴生活方式的最佳做法。例如，如果我有一個依賴於ISession的Repository類。如果存儲庫設置爲PerWebRequest，但ISession設置爲瞬態，這是否會對windsor釋放組件造成任何問題，以便GC可以正確清理？

從邏輯上看，這似乎是行得通的，因爲在網絡請求期間每個對存儲庫的請求都將獲得對同一實例的引用。該實例將持有對實例化的單個ISession的引用，以便在首次請求時滿足Repo依賴關係。因爲PerWebRequest跟蹤，Windsor會知道Repo何時超出範圍，因此應該知道何時清理ISession。

但是，KrzysztofKoźmic的this post意味着你不應該有一個組件依賴於比自己更短的生活方式。

[編輯]

我的問題是，它是可以接受的已溫莎組件依賴於一些與較短的生活方式比本身（即PerWebRequest部件 - >瞬態分量）？

Answer 1

是的，它可以非常好，特別是在something --> transient的情況下。你需要擔心的是：

• 我是否強迫這個組件生存（並留在內存中）比它應該更長？
• am我不會在我所依賴的對象被自動釋放的情況下結束（比如在單例中，依賴於每個Web請求對象，當第一個Web請求結束時釋放） 。在這種情況下，您最終會使用處於無效狀態的對象，這取決於您如何實現它將引發異常（快速失敗）或行爲異常（您不想在那裏）。

如果您已經考慮了這兩種情況，以及潛在的其他一些特定於您的情況的因素，那麼您可以做出明智的選擇來依賴依賴關係。

或者你可以把它通過一個間接層傳遞依賴：

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

單例對象可能依賴於它使用的工廠來拉取它所用來執行其工作的每個Web請求對象。因此，如果實施得當，它不會有上面討論的缺點。

希望有所幫助。

哦，和我的其他答案，你鏈接到你的問題 - 它說經驗法則，不嚴格的法律。在大多數情況下這可能是正確的，但是，正如上面所討論的，如果你知道自己在做什麼，就可以打破它。這也是爲什麼溫莎的診斷檢測的情況下，被稱爲原因潛在錯誤配置的組件

Answer 2

爲什麼你會在一個Web請求中有多個會話。我在Web應用程序中常用的關於會話的一種模式是工作單元模式。 Web請求是工作單元。

Answer 3

瞬間生活方式只有在您明確釋放它或其父母時纔會被釋放。因此，具有每個Web請求生活方式的組件的依賴關係的臨時組件應該沒問題。