摘要一個可重用的庫

Locate the correct composition root for a .NET library

幫助澄清有關依賴性注入。 Steven的詳盡答案（用幾句話表示，如果可能的話）表示可重複使用的庫是一個特例，這裏我們可以使用poor-man-injection（查看完整性的答案）。

研究AutoFixture的源代碼，你可以注意到主程序集在任何地方都使用DI而不依賴於容器;在Mark Seemann書中得到了很好的解釋。

現在的問題是：有人可以引入一種模式（或良好的做法）來抽象組成的根，而不使用容器？

附加說明（可選）：

背襯AutoFixture其中該組合物在根Fixture類型構造發生;我認爲*Relays類用於以類似的方式對實例進行分組，一些DI庫具有模塊的概念。有趣的是，有一種名爲BehaviourRoot的類型位於圖的頂部（這是我正在尋找的抽象類型？）。

來源

2013-03-14 jay

description of the Composition Root pattern明確聲明它可以在沒有DI容器的情況下實施。該模式與容器使用無關，可以在有或沒有容器的情況下使用。

組合根是應用程序的入口點。根據定義，它有沒有來電者所以它是沒有意義的抽象它。

引述上面的文章：

的構成根是應用基礎架構組件。

只有應用程序應該有組合根。 庫和框架不應該。

（粗體我的重點）

AutoFixture是一個庫，因而沒有構成根。本着建立DI-friendly library的精神，Fixture班是Façade。

來源

2013-03-14 07:06:17

+1和這個答案。不知道是否有點題外話，也許繼續讀這本書，我可以得到答案：但我試着問。一個例子：我有一個像'Fixture'一樣的Facade，它提供了一個消費類型專用於可重用庫的服務。所有類型都通過構造函數注入來使用DI。在某些時候（我認爲在Facade ctor中）應該創建圖表。如果這不是組成的根，如何調用它？如果這種處理方式是正確的，你可以提供一個評論嗎？（例如使用適當的圖案或指示...） – jay 2013-03-14 08:03:50

插件怎麼樣？插件是否可以有組合根？該插件具有它需要管理的依賴關係，而與其託管的應用程序無關。 – Philippe 2013-09-13 16:10:27

一個好的插件會遵循OCP，所以雖然它可能具有依賴關係，但這些依賴關係可能不必捆綁在插件本身中，但可以從其他插件中導入。這就是管理可擴展性框架（作爲示例）明確建模*進口*和*出口*的原因。因此，如果插件具有其自己的組合根，它將打破OCP。如果設計得當，所有庫都是插件，所以上面的答案仍然成立。 – 2013-09-14 08:24:17

摘要一個可重用的庫

回答

相關問題