我們在我們的應用程序中使用Castle Windsor的類型工廠,並發現儘管他們將IoC容器從應用程序中「隱藏」,但某些抽象現象肯定是漏。也就是說,工廠必須實施一種釋放方法,以便解決的實例可以安全地處置或以其他方式退役。畢竟,你永遠不知道何時會引入可能需要新語義的組件「負擔」中的某些內容,即下游依賴關係。因此,你總是假設(實際上)你從一個打字工廠返回的所有東西都是IDisposable
- 也就是說,你應該追蹤它並將其還給你。因此,我們希望返回IReference<T>
對象,其方法Dispose
將它們返回到工廠以強制執行此行爲,而不是依賴於陌生人調用該釋放方法的善意。如何檢查Castle Windsor中的有害註冊
但是,在很多情況下,我們高度肯定服務類型不需要這些語義。而且我們知道溫莎城堡甚至不會打擾跟蹤真正的瞬態物體,而且沒有下游的負擔。垃圾收集器將會很好。在這種情況下,我們會對沒有退貨方法的工廠感到滿意。用戶可以讓垃圾回收做它的事情。
我們想要做的是檢查所有類型工廠註冊後內核和類型工廠設施的註冊,看看是否違反了這些假設。也就是說,對任何類型的工廠方法發出警告,這種方法返回的類型沒有IDisposable
語義,但最終被註冊了一個負擔。 (可能需要對此進行定製;例如,取決於應用程序範圍的單例,或者每個請求對象可以接受)。
什麼是用於開始查詢和/或執行這些約定的最佳公共接口?或者我們應該停止使用這麼多類型的工廠?
我非常希望跟蹤需要跟蹤的組件 - 只是在應用程序中可能讓少量組合根源泄漏的情況下才會發出警告。 – 2011-06-13 03:21:03