循環依賴關係

Question

考慮基於使用WinForms的MVC模式的正常客戶訂單應用程序。 視圖部分增長過多（超過4000個文件），需要將其拆分爲更小的部分。

---

在這個例子中，我們將使用3個項目的視圖部分：

• 主要 - 有依賴於其他2個項目。用列表實例化表單。
• 客戶 - 有2種形式 - 客戶名單和客戶詳細信息。
• 訂單 - 有2個表格 - 訂單清單和訂單明細。

---

在客戶信息形成也有訂單客戶的名單。該列表是從OrdersController收到的，所以獲取它沒有問題。當用戶選擇一個訂單時，該列表將獲得它的guid並將其作爲參考訂單明細表單傳遞給它。

這意味着我們需要在客戶項目中引用訂單項目。（1）

但是，在訂單明細表中，還有一個鏈接指向訂單的客戶。點擊後，應打開「客戶詳細信息」表單。

這意味着我們需要在訂單項目中引用Customers項目。（2）

由式（1）和（2）我們將有訂單和客戶項目之間的循環依賴。

---

這又如何避免？某種插件架構？該項目已經開發完畢，最好的解決方案將涉及儘可能少的代碼更改。

Answer 1

將至少一種類型更改爲接口。

例如有一個ICustomer接口和一個實現此接口的Customer類型。現在將ICustomer添加到訂單項目，並從客戶項目中設置對訂單項目的引用，以便您可以實現該界面。 Order類型現在可以在不知道實際實現的情況下針對ICustomer類型工作。

而爲了更好的解決方案:-) 創建一個ICustomer和一個IOrder接口並將它們添加到第三個庫項目中。並從另外兩個參考這個項目，並且只與接口一起工作，從不與實現。

Answer 2

如果他們緊密耦合，也許他們不應該分裂。

Answer 3

提取接口並將它們放入單獨的程序集中。由於您使用的是MVC架構，因此不應該很難。查看Microsoft Composite UI應用程序塊以獲取示例和最佳實踐。

Answer 4

我認爲你的主要問題不是你的應用程序的體系結構。您需要了解邊界以及如何劃分它們之間的功能。像你這樣的部門是非常虛構的，你試圖根據域對象拆分應用程序。嘗試使用用戶角色或功能主題來解決問題，問題可能會消失。

從技術角度來看，我不明白爲什麼你的意見應該意識到彼此的存在 - 這聽起來有點奇怪。你不會分裂你的數據和業務邏輯，並且在一天結束時，GUID只是一個你可以輕鬆地通過不同方法傳遞的叮咬。