我们当前的项目遇到了循环依赖问题。我们的业务逻辑程序集使用 SharedLibrary 程序集中的类和静态方法。SharedLibrary 包含一大堆帮助函数，例如 SQL 读取器类、枚举器、全局变量、错误处理、日志记录和验证。
SharedLibrary 需要访问业务对象，但业务对象需要访问 SharedLibrary。老开发者通过在共享库中复制业务对象的功能来解决这种明显的代码异味（非常反 DRY）。我现在花了一天时间尝试阅读有关解决此问题的选项，但我遇到了死胡同。
我对架构重新设计的想法持开放态度，但只是作为最后的手段。那么我怎样才能拥有一个可以访问业务对象的共享助手库，而业务对象仍然访问共享助手库呢？
您可以仅为值对象（无逻辑）和接口创建单独的项目。
让您的共享库类实现接口，而业务库依赖于接口（我在这里听到更多可测试和解耦的代码吗？更不用说您从共享库中删除了依赖项）。
理想情况下，您的共享库所依赖的业务对象也可以依赖于这个额外的项目。如果业务对象过于复杂，您也可以将它们转换为接口。
您将拥有两个项目，而不是相互依赖，而仅在另一个项目中只有“虚拟”对象（没有逻辑）：
业务 ---> 接口和值对象 <--- 共享库
现在这些被解耦了=）
任何时候你有一个“共享”库，你绝对不能引用你的业务实体项目。如您所见，这样做会导致此问题发生。
对此的解决方案是从共享库中删除所有与业务实体相关的代码，并重新架构以消除对该帮助代码的需求，或者将该帮助代码放置在业务实体项目本身中。
一种解决方案是在两者之间放置一个外观模式。在这里，您将避免从共享库直接访问/依赖您的业务对象。相反，您将使用一个充当您的 lib 和 BO 之间的外观的层。通过这种方式，您可以将共享库打包并解耦。