循环依赖解决方案答案

【问题标题】：Circular Dependency Solution循环依赖解决方案
【发布时间】：2010-04-07 22:54:18
【问题描述】：

我们当前的项目遇到了循环依赖问题。我们的业务逻辑程序集使用 SharedLibrary 程序集中的类和静态方法。 SharedLibrary 包含一大堆帮助函数，例如 SQL 读取器类、枚举器、全局变量、错误处理、日志记录和验证。

SharedLibrary 需要访问业务对象，但业务对象需要访问 SharedLibrary。老开发者通过在共享库中复制业务对象的功能来解决这种明显的代码异味（非常抗 DRY）。我已经花了一天时间尝试阅读有关解决此问题的选项，但我遇到了死胡同。

我对重新设计架构的想法持开放态度，但只是作为最后的手段。那么我怎样才能拥有一个可以访问业务对象的共享助手库，而业务对象仍然访问共享助手库呢？

【问题讨论】：

显而易见的问题是：为什么共享库需要访问业务对象？如果你能回答这个问题，你就会有一个解决方案。
SharedLibrary 有一个包含静态属性的抽象全局变量类。这些属性是从数据库中的值创建的，因此需要业务对象，这只是其中的一个示例。当然，业务对象需要访问这些常量。
这就是为什么我从不使用“共享”之类的模糊术语来描述库。它实际上是做什么的？你所谓的共享库显然有太多的责任，也许业务对象库也有。通常，这些解决方案是通过将真正的独立类/接口放入它们自己的库中来解决的。

【解决方案1】：

您可以为值对象（无逻辑）和接口创建单独的项目。

让你的共享库类实现接口，业务库依赖于接口（我在这里听到更多可测试和解耦的代码吗？更不用说你从共享库中删除了依赖项） .

理想情况下，您的共享库所依赖的业务对象也可以依赖于这个额外的项目。如果业务对象太复杂，也可以转成接口。

您将拥有两个项目，而不是相互依赖，而仅在另一个项目上只有“虚拟”对象（没有逻辑）：

业务 ---> 接口和值对象

现在这些已经解耦了 =)

【讨论】：

如果您要走这么远来消除依赖关系，为什么要在距离终点线不到 5 英尺的地方停下来而不是完全消除依赖关系呢？那时，您将不再有依赖于业务实体的代码，并且可以将核心真正共享的代码留在共享项目中。这将是我的答案。
@Chris 这不是一个巨大的变化。这将需要一些重构，但不需要大的重新设计或改造。
好的，所以我理解这里的概念，但我很难理解如何实现它。因此，如果 SharedLibrary 引用了 BusinessObjects 并且都引用了接口层，那么我会这样做，例如： //sharedlibrary public abstract class MSSqlReader{ //各种方法 } //接口层公共接口 IMSSqlReader {} //业务对象 IMSSqlReader obj = new IMSSqlReader( );粗略地说，这不起作用，obj 无权访问 MSSqlReader。 BusinessObject 如何使用接口访问 SharedLibrary 中的对象？
我认为你应该复习你的一般SOLID设计知识butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod这个案例特别是I，即接口隔离原则。您很可能还希望使用 D 来实现它，它是依赖反转部分。
@gfoley 正如 Chris 所说，这里的依赖注入是关键。您不需要 new IMSSqlReaderImpl()，而是在构造函数中获取它并在您的类中简单地使用它

【解决方案2】：

只要您有一个“共享”库，就绝对不能引用您的业务实体项目。如您所见，这样做会导致此问题发生。

解决方案是从共享库中删除所有与业务实体相关的代码，并重新架构以消除对帮助程序代码的需求，或者将帮助程序代码放在业务实体项目本身中。

【讨论】：

【解决方案3】：

一种解决方案是在两者之间放置一个外观模式。在这里，您将避免从共享库直接访问/依赖您的业务对象。相反，您将使用一个充当您的 lib 和 BO 之间的外观的层。通过这种方式，您可以将共享库打包并解耦。

【讨论】：