.NET IoC：預先配置庫組件以便於使用

Question

雖然我之前也有過類似的問題，但對整個IoC/DI主題的掌握以及我想要實現的目標都很少，所以在這裏再次....

我正在建立一個共同使用我們公司內的圖書館。公共API中最常用的部分已經是IoC友好的，但在較低級別的領域，仍然有一些新的事情正在進行，我想擺脫它（儘管此時更多的是出於正式的原因而不是真正的必要性）。

這本身就很容易做到，但是當然每次使用庫時，所有組件都必須重新連線。由於這幾乎總是看起來一樣，我通常只是將這些默認註冊包裝在一個Autofac模塊中並完成它。

（這裏的問題1：請問這個模塊中的主庫程序走，還是應該是一個獨立的包，即使Autofac很可能是與庫所使用的唯一的IoC容器？）

現在的問題是我目前是公司中唯一真正看到IoC目的的開發人員，或者知道IoC容器的用途，更不用說它是如何使用的，而告訴其他人可以使用它是一個壞主意Autofac軟件包或者使用窮人的DI手動建立一個十幾個對象的圖形。 （我知道那些傢伙 - 他們會把它留在一邊，建立他們自己需要的東西，因爲無論如何，我和我所有的許多小班都瘋了）。

我想解決這個問題的方法是添加一些類似服務定位器可從中爲通常需要的類型（它們看起來與Autofac模塊連接的那些相同）提供預先配置的對象，可能由輕量級IoC容器在內部連接。我知道Service Locator是一個反模式，它創建了哪些類型的問題，我從來不會將它用作對象組合的（我）方法，但作爲IoC/SOLID的「快捷方式」受損，它可行嗎？我還有什麼其他選擇？在這種情況下，將Autofac模塊與庫包含在一起可能更有意義，並且只需將「服務定位器」作爲它的前端？

Answer 1

對於框架，不同的規則比業務線應用程序更適用。在我看來，這也適用於應用依賴注入。您在查看Microsoft Patterns & Practices Enterprise Library的設計時可以看到這一點。它完全是圍繞依賴注入模式設計的，但普通用戶不會知道這一點。它使用工廠來讓用戶的生活更輕鬆。在你的情況下，強迫其他開發人員使用依賴注入並不明智，因爲這可能只會讓他們煩惱，因爲你正在做的事情看起來更加困難，他們不會看到它的好處。這可能會讓他們對整個DI事情產生負面的感受，並且你將會失去在後面介紹DI的可能性（因爲他們已經不喜歡它）。

會在此模塊中主庫組裝去，還是應該是一個獨立的包

我通常不會在圖書館本身集成這一點，因爲從建築的角度來看，你根本就沒有希望您的圖書館依賴任何DI容器。但是，當您查看企業庫時，您會發現它很難依賴Unity DI框架。您可以更改EntLib以使用不同的容器，但EntLib仍然引用Unity。這允許框架設計者爲用戶提供方便的工廠方法，並且允許使用框架，而不必在應用程序中調用某種'Framework.Bootstrap`方法。

盡你所能地設計你的框架，銘記SOLID原則，因爲你知道這只是最好的事情。它還允許您以這種方式展示未來應用程序設計的方式（並可能對依賴注入感興趣的其他人）。但作爲一個框架設計師，你必須考慮你的用戶是誰，並想出一個適合他們的API。牢記.NET框架設計指南可以幫助很多人。

查看Enterprise Library時，您會看到根/主類型有一個工廠。其他的一切都是爲你解決的。我認爲這是一條路。不要讓用戶用API來打擾用戶，尤其是對於正常/簡單的用例。