溫莎城堡和動態佈線

Question

我在過去的幾年裏一直是溫莎的用戶。在Fluent註冊API之前，我會在Xml註冊和大量的AddComponent（）代碼之間切換。我們一直很高興地使用Fluent註冊API和安裝程序很長一段時間。我已經得到了來自不同著作的印象是這樣的：

http://docs.castleproject.org/Windsor.XML-Registration-Reference.ashx

該XML註冊方法已在不遠的失寵，它不會讓我感到吃驚，如果它被標記棄用在某些點未來。

現在，對於我的問題：Fluent註冊API和安裝程序適用於自動佈線場景（即，當我想讓Windsor知道如何構建我的對象圖時）。自動佈線是絕大多數IoC用例，但是當自動佈線不可行時呢？換句話說，我有一個服務的多個實現，我需要告訴溫莎如何構建我的對象圖的一部分。我已經使用Xml註冊方法做了很多次，但是現在還有更受歡迎的方法嗎？由於它的未來似乎不確定，我對使用Xml註冊方法猶豫不決，但我不知道如何用Windsor來實現這一點。

我的使用情況是：

• 系統需要能夠在QA測試交換實現（即 信貸檢查和欺詐檢測處理，我們要測試 不會對信貸局API的依賴）
• 我們的 系統中的供應商模式，我們需要在部署時有條件地打開和關閉不同的 實現。

這一切似乎都非常適合IoC，我們擁有所有構建基塊，但要確保我正在採取溫莎最適合未來的方法。

UPDATE： 雖然我喜歡的功能切換方法，我最近發現一個溫莎特點，就是在這方面非常有用 - Fallback Components。我將把這個編輯留給任何可能在後來偶然發現的人。

Answer 1

完全通過XML配置您的DI容器是容易出錯，冗長而且太痛苦。 XML配置的可能性始終是您使用基於代碼的配置所能做的一個子集;代碼總是更具表現力。

雖然您的DI配置取決於部署時間配置，但由於您需要的旋鈕數量通常相當小，因此使用配置標誌通常比使用完全限定類型名稱污染配置文件更好。

或者讓我換一種說法，當您的配置文件中有大量DI配置放置在您的配置文件中，因爲您可能想在部署時更改它們，請再考慮。許多變化無論如何都需要測試（由開發人員進行測試），所以您不希望操作團隊的某個人爲此做些調整。當您需要開發人員查看並驗證它時，無需重新編譯項目有什麼優勢？這實際上更快嗎？無論如何，開發者仍然必須啓動應用程序。

這是一種虛假的靈活性，實際上是一個糟糕的界面設計（xml是維護和運營部門的接口）。順便說一句，你是否需要記錄配置文件應如何更改？ 而不是描述在xml文件的中間某處有效的完全限定類型名稱的列表，是不是很容易寫出所有你要寫的內容是「在這個字段中放置'false'以禁用... 「？

下面是如何使用的配置開關的一個示例：

bool detectFraught = 
    ConfigurationManager.AppSettings["DetectFraud"] != "false"; 

container.Register(
    Component.For(typeof(IFraughtDetector)).ImplementedBy(
     detectFraught ? typeof(RealDectector) : typeof(FakeDetector)); 

參看配置開關現在如何是一個簡單的布爾標誌。這使得配置文件更易於維護，因爲配置現在是一個簡單的布爾開關，而不是完整的類型名稱（可能會拼錯）。

當然做["DetectFraud"] != "false"本身並不好，但這可以簡單地通過創建一個強類型配置助手來解決。

Answer 2

This answer也可能有幫助。允許您在運行時動態地提供實現。雖然，聽起來像你不需要動態的，並且不太明顯發生了什麼。

Answer 3

有沒有計劃過時或刪除溫莎的XML配置支持。

是的，你是對的，由於它的許多缺點，它不是一個首選的方法。

您可以在XML中做的任何事情都可以在代碼中完成（請注意，inverse是不正確的）。

還要記住XML不是全有或全無。有很多方法可以實現您提供的場景，而無需使用XML進行註冊。

• 功能切換
• 條件編譯
• 的if/else在installer基礎上的appSettings標誌
• 其他...

我在不同的項目中使用他們每個人以往。