帶有隔離的分層應用中的DI

Question

假設我們有三層;用戶界面，業務，數據。我們正在使用DI。我不想通過UI訪問數據層。

的問題是有關數據層的DI註冊。組合根在UI中，我不想在那裏提及任何數據。我發現這個answer。據我所知，我們應該參考所有圖層，並認爲它們不是圖層庫。這樣我可以指定我的業務層使用數據層或其他任何我想要的。畢竟這是爲什麼DI在附近。

這是正確的，但有一個問題！我們不應該在UI上使用數據層。但是，一旦開發人員意外地從UI引用數據，另一個人將數據層中的某些內容直接注入到UI類。所以他跳過了我不想要的業務層。

我該如何處理這種情況？我想要有一些限制，但另一方面，我想要DI靈活性。

當然有些人認爲我們可以有一個單獨的庫，只爲依賴註冊。

什麼這裏是最好的模式？

Answer 1

您鏈接到答案有兩個答案，這說明擁有組成的根和在同一程序UI層是沒有問題的：

• 你誤用物理邊界邏輯層：組件是部署單元並可以包含多個邏輯層。層甚至可以散佈在組件中。想想4+1 view。組合根可能與您的UI位於同一個程序集中，但它不在UI層中，並且雖然組合根取決於數據訪問層，但UI層不會（儘管其組裝方式）。
• 代碼評審對於質量或軟件以及團隊內知識共享非常重要。如果您現在沒有進行代碼審查，那麼您一定要開始執行代碼審查。這些代碼審查可以包括檢查架構指南，例如您在問題中描述的規則。
• 雖然程序集分離爲您提供編譯時支持，但編譯器無法檢查大多數體系結構規則。此外，當開發人員添加對DAL程序集的引用時，編譯器不會投訴。開發人員總是會想辦法打破規則。再次，代碼評論幫助了很多。此外，作爲架構師，您可以開始使用諸如NDepend之類的工具來自動驗證某些體系結構規則。但是當你應用構造器注入時，也可以使用單元測試，因爲可以通過簡單地反映UI層中類型的構造函數來找到依賴關係。

但是，如果您認爲這是一個問題，爲什麼不直接在自己的程序集中移動UI層？啓動程序集不需要UI層！如果您創建Windows窗體應用程序，請將所有窗體移至其自己的程序集。如果您正在創建ASP.NET MVC應用程序，請將控制器和視圖移至其自己的程序集。根據你構建的應用程序的類型，你將不得不運用一些技巧來實現這個功能，但對於.NET中的大多數項目類型來說，這是可能的。

真正的問題是，這是否值得麻煩？如果你想要這樣做，以防止必須做代碼評論，你是在愚弄自己。