您何時使用Common Service Locator？

Question

我一直在尋找Common Service Locator作爲我的IoC容器的抽象方法，但我一直在注意到有些人強烈反對這種類型。

有人推薦不要使用它嗎？總是使用它？或有時使用它？ 如果有時候，那麼你會在什麼情況下使用它，以及你不會使用它的情況。

Answer 1

想象一下，您正在編寫供第三方開發人員使用的庫代碼。您的代碼需要能夠創建這些開發人員提供的服務對象。但是，您不知道每個呼叫者將使用哪個IoC容器。

通用服務定位器可讓您在不強制給用戶提供給定IoC的情況下應對上述問題。

在你的庫本身，你不妨在國際奧委會註冊自己的班，現在它得到了很多困難，因爲你需要選擇一個國際奧委會自己使用，不會在你的來電的方式獲得。

Answer 2

最近我對服務定位器概念做了一些閱讀。這是一種有助於減少耦合的方式，但需要代碼耦合到定位器 - 而不是定位器的支持容器，而是定位器本身。這是一種折衷，但在正確的情況下可能會有所幫助。

可能有用的一種情況是，當你有沒有使用DI的代碼時，比如遺留代碼 - 我現在就在這條船上。通過SL拉入所需的對象，而不是直接創建它們，允許增加一些抽象。我認爲這是SL和DI/IoC之間的中間步驟。

Answer 3

我注意到反對使用CSL的一個論點是錯誤的，因爲開發人員認爲這個庫只能執行Service Locator模式。但是，情況並非如此，因爲它也很容易與依賴注入模式一起使用。

但是，CSL庫專爲需要允許用戶註冊依賴關係的框架設計人員設計。由於該庫將直接調用CSL，因此從框架的角度來看，我們正在討論SL模式，因此它的名稱。

然而，作爲一個框架設計師，對CSL的依賴不應該輕視。爲了您的框架的可用性，通常擁有自己的DI機制會更好。一個非常常見的機制是在配置文件中設置依賴關係。整個.NET框架都使用這種模式。幾乎每個依賴項都可以替換爲另一個。 .NET提供程序模式建立在此之上。

當您作爲框架設計師依賴CSL時，用戶使用您的應用程序將會更困難。用戶將不得不配置一個IoC容器並將其連接到CSL。但是，框架無法驗證配置，因爲可以在使用.NET配置系統時進行配置，而配置系統作爲所有類型的驗證支持。

Answer 4

如果你有需要服務的庫代碼，並且這個代碼可以在更大的框架/運行時的上下文中託管，那麼框架/運行時需要提供一種機制，在啓動時可以運行一些自定義代碼其中您可以初始化您的容器並註冊依賴關係。 CSL可能出現問題的一個很好的例子是在MSCRM的上下文中使用它。您可以通過註冊MSCRM框架在特定事件上執行的插件來執行自定義業務邏輯。您遇到的問題是您在哪裏運行註冊邏輯，因爲您沒有可以訂購的「啓動」事件來設置您的DI容器。即使您可以以某種方式設置您的DI，您也需要將CSL和DI庫放入GAC，因爲這是從插件向第三方代碼發出呼叫的唯一方式（要添加到您的部署清單的另外一個項目）。 在像這樣的場景中，最好將你的依賴作爲構造函數參數，調用代碼可以根據它認爲合適的方式進行初始化（通過構造函數注入或手動「新建」適當的接口實現）。