我正試圖將非常鬆散的耦合設計放在一起。鬆散耦合設計中的常見定義
但我不能決定如何處理常見的定義。
現在我通過將它作爲外部DLL添加它分開擔憂。通過注入和接口，我的域可以在不知道實現的情況下使用我的業務邏輯。
我遇到的問題是，所有我的組件都要鬆散耦合，他們需要實現相同的接口。我的解決方案是一個單獨的項目（dll），只有所有的定義。 這開始的很好，但似乎變得膨脹並將所有代碼鏈接在一個dll依賴項上。
什麼是最實用的方法？
謝謝！
編輯
對不起，我想我最初誤解了你的問題。所以你有一個包含你的接口的程序集，而你在其他程序集中使用DI來創建你的依賴對象。我傾向於在我的應用程序中創建一個核心程序集，其中包含應用程序的主要行爲（智能實體，枚舉和接口）。這個程序集很少依賴於應用程序的其餘部分，但依賴程度很大。以此項目爲例 - whocanhelpme.codeplex.com。你可以稱這個核心臃腫，但根據定義，它需要非常豐富。
你可能會發現，您的許多抽象的單位都遵循常見的設計模式。下面是給每個人一個很好的說明一個網站 - 你可以從這些（觀察，工廠，適配器等）得出名字：
我會說，該層只應瞭解下一層及其接口，因此可以將接口與其實現一起放置，然後在鏈中的層（程序集）之間添加引用。
您可以使用引導程序模式配置DI並通過定位器進行解析。關於日誌記錄，緩存等橫切關注問題，應該爲每個圖層引用單獨的程序集。在這裏，您還可以使用合同，並且在未來可能會將這些橫切功能替換爲實施相同合同的另一個裝配。
希望這有助於至少一點:)
我正在使用最接近工廠方法。但通過鬆散地耦合我的圖層（GUI，Business，Service，Data），他們都需要知道具體對象可以傳遞的共享定義（接口，枚舉，..）。所以他們都需要知道使用具體實例的接口，這會創建一個交集和依賴定義。如果我嘗試將它們提取到單獨的dll，並且我將進入我的UserManagement邏輯，我還將加載我的DAO對象fe的定義。 （很像需要建築物的藍圖，當你想打開一扇門時） – Tim 2011-03-10 12:06:40
對不起，我想我最初誤解了你的問題。所以你有一個包含你的接口的程序集，而你在其他程序集中使用DI來創建你的依賴對象。我傾向於在我的應用程序中創建一個核心程序集，其中包含應用程序的主要行爲（智能實體，枚舉和接口）。這個程序集很少依賴於應用程序的其餘部分，但依賴程度很大。看看這個項目爲例 - http://whocanhelpme.codeplex.com/。你可以稱這個核心**膨脹**，但根據定義，它需要非常豐富。 – 2011-03-10 13:02:40
謝謝！我正在檢查它並試圖獲得您的架構的概述。我會再讀一點，並嘗試重新安排我的項目，以結合「核心」功能，而不是試圖使我的接口/枚舉「可導出」。 – Tim 2011-03-10 13:26:44