循环依赖关系

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只是一个你可以轻松地通过不同方法传递的叮咬。