循环依赖
考虑使用WinForms的基于MVC模式的普通客户订单应用程序。
视图部分已增长太多(超过4000个文件)，需要将其拆分为较小的文件。
对于此示例，我们将在视图部分中使用3个项目：
- Main-依赖于其他2个项目。用列表实例化表单。
- 客户-有2种形式-客户列表和客户详细信息。
- 订单-具有2种形式-订单列表和订单详细信息。
在客户详细信息表单上，也有该客户的订单列表。该列表是从OrdersController接收的，因此获取它没有问题。当用户选择一个订单时，列表将获得指导，并将其作为对"订单详细信息"表单的引用。
这意味着我们需要在"客户"项目中引用"订单"项目。 (1)
但是在订单明细表上，也有指向创建该订单的客户的链接。单击后，它将打开"客户详细信息"表单。
这意味着我们需要在"订单"项目中引用"客户"项目。 (2)
从(1)和(2)，我们将在Orders和Customer项目之间具有循环依赖关系。
如何避免这种情况？某种插件架构？该项目已经开发完毕，最好的解决方案将包括尽可能少的代码更改。
解决方案
如果它们是如此紧密地耦合，那么也许就不应该将它们分开。
提取接口并将它们放在单独的程序集中。由于我们使用的是MVC架构，因此不难。查看Microsoft Composite UI Applications块以获得示例和良好实践。
将至少一种类型更改为接口。
例如，具有ICustomer接口和实现此接口的Customer类型。现在，将ICustomer添加到订单项目，并从客户项目中设置对订单项目的引用，以便我们可以实现该接口。现在，Order类型可以与ICustomer类型一起工作，而无需知道实际的实现。
为了更好的解决方案:-)
创建一个ICustomer和一个IOrder接口，并将它们添加到第三个库项目中。并从其他两个项目中引用该项目，并且仅使用接口，而不使用实现。
我认为主要问题不是应用程序的体系结构。我们需要了解边界以及如何在其中划分功能。像我们这样的划分是非常人为的，我们尝试根据域对象拆分应用程序。尝试使用用户角色或者功能主题执行此操作，问题可能会消失。
从技术角度来看，我不明白为什么你们的观点应该彼此了解，这对我来说听起来有些奇怪。我们不会拆分数据和业务逻辑，最终，GUID只是我们可以使用不同方法轻松传递的一个障碍。
