architecture - 装配循环依赖是设计中的错误吗

Question

我有N个申请。每个应用程序至少包括以下程序集：

• 商业逻辑
• 数据访问

在某些情况下，应用程序1需要调用应用程序2的业务逻辑层的方法，应用程序2需要调用应用程序1的业务逻辑层的方法。这种情况导致应用程序1的业务逻辑层和应用程序2之间的程序集循环依赖。我知道它可能会导致构建过程中出现一些问题。现在我的问题是：“这是建筑设计的错误吗？如果是，如何解决？”

Answer 1

这只是告诉您可能需要重新设计系统。我总是会避免循环依赖，因为你混合了责任，以后会导致各种问题。

绘制您的组件和关系并将它们中的每一个放在指定的层中。Onion 架构是设计系统和识别所有资产、职责和它们之间关系的好方法。在这里和这里阅读。

在您的情况下，您需要一个由两个客户端使用并包含共享内容的组件。但是根据您提供给我们的信息，我们无法猜测如何。

Answer 2

如果 App2 必须调用 App1 的业务逻辑层，那么在您获得循环依赖之前，这应该是一个危险信号（因为现在确实是 app1 和 app2 的业务逻辑）。

一个常见的解决方案正是您在用 OOP 语言抽象基类时所做的。在这种情况下，找到共享的部分并将它们从单个“应用程序”下方移出，并将它们放入可以轻松共享的库中。

在您的情况下，我会抓住共享的业务逻辑操作并将它们放在自己的程序集中，并适当命名，这样两者都可以毫无问题地使用它。

Answer 3

可以有 2 个相互依赖的程序集（例如System.dll，System.Configuration.dll在 .NET Fx 中相互依赖）。但正如您可能经历过的那样，您必须努力对抗 Visual Studio 强制执行以避免这种情况。

显然，程序集之间的非循环依赖是您必须实现的目标。否则，您的程序集无法独立开发、编译和测试。

共同的范式，是BusinessLogic使用DataAccess而不是相反。如果您希望DataAccess能够回调BusinessLogic，通常的方法是：

• DataAccess在程序集中定义一个回调接口
• 在程序集中实现这个回调接口BusinessLogic（因此BusinessLogic程序集引用DataAccess程序集，但不是相反）
• 将一个或多个实现此接口的对象从BusinessLogictoDataAccess传递给定义在DataAccess中的方法，该方法将回调接口作为参数。

DataAccess能够回拨并不是BusinessLogic一件被禁止的事情，但您应该质疑自己为什么要这样做，并且您应该尝试将这些回拨数量限制在严格的最低限度。

---

就个人而言，我更喜欢将程序集中的命名空间视为组件，具有非循环命名空间依赖关系，并避免使用程序集工件来定义组件。这在我撰写的两本白皮书中有所体现，可在此处获取。