循环依赖解决方案
我们当前的项目遇到了循环依赖问题。我们的业务逻辑程序集使用 SharedLibrary 程序集中的类和静态方法。 SharedLibrary 包含一大堆辅助函数，例如 SQL Reader 类、枚举器、全局变量、错误处理、日志记录和验证。
SharedLibrary 需要访问业务对象，但业务对象也需要访问 SharedLibrary。老开发人员通过复制共享库中业务对象的功能来解决这个明显的代码味道（非常反DRY）。我现在花了一天时间尝试了解解决此问题的选项，但我陷入了死胡同。
我对架构重新设计的想法持开放态度，但只是作为最后的手段。那么，我怎样才能拥有一个可以访问业务对象的共享助手库，同时业务对象仍然可以访问共享助手库呢？
Our current project has ran into a circular dependency issue. Our business logic assembly is using classes and static methods from our SharedLibrary assembly. The SharedLibrary contains a whole bunch of helper functions, such as a SQL Reader class, Enumerators, Global Variables, Error Handling, Logging and Validation.
The SharedLibrary needs access to the Business objects, but the Business objects need access to SharedLibrary. The old developers solved this obvious code smell by replicating the functionality of the business objects in the shared library (very anti-DRY). I've spent a day now trying to read about my options to solve this but i'm hitting a dead end.
I'm open to the idea of architecture redesign, but only as a last resort. So how can i have a Shared Helper Library which can access the business objects, with the business objects still accessing the Shared Helper Library?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以仅为值对象（无逻辑）和接口创建一个单独的项目。
让您的共享库类实现接口，并且业务库依赖于这些接口（我在这里听到更多可测试和解耦的代码吗？更不用说您从共享库中删除了依赖项）。
理想情况下，您的共享库所依赖的业务对象也可以依赖于这个额外的项目。如果业务对象太复杂，也可以将它们转化为接口。
您将拥有两个不相互依赖的项目，而仅依赖于另一个仅具有“虚拟”对象（无逻辑）的项目：
业务 --->接口和值对象 <--- 共享库
现在它们是解耦的 =)
You could create a separate project only for value objects (no logic) and interfaces.
Have your shared library classes implement the interfaces, and the Business library depend on the interfaces (do I hear more testable and decoupled code here? Not to mention you remove the dependency from the Shared Library).
Ideally, you could have the business objects on which your shared library depend on this extra project too. If the business objects are too complex, you could also transform them into interfaces.
You will have both projects not depending on each other, but only on another project with only "dummy" objects (no logic):
Business ---> Interfaces and value objects <--- Shared Library
Now those are decoupled =)
每当您拥有“共享”库时，您绝对不能引用您的业务实体项目。正如您所看到的，这样做会导致此问题发生。
解决方案是从共享库中删除所有与业务实体相关的代码，并重新设计架构以消除对该帮助程序代码的需求，或者将该帮助程序代码放置在业务实体项目本身中。
Anytime you have a "shared" library you absolutely must not ever reference your business entity project. Doing so will cause this issue to happen as you obviously see.
The solution to this is remove all of the business entity dependent code from the shared library and either rearchitect away the need for that helper code or place that helper code inside the business entity project itself.
一种解决方案是在两者之间放置立面图案。在这里，您将避免从共享库直接访问/依赖业务对象。相反，您将使用一个层作为库和 BO 之间的外观。通过这种方式，您可以将共享库打包干净并解耦。
One solution would be to put a facade pattern in between. Here you would avoid direct access/dependency to your business objects from the shared library. Instead, you would be using a layer that acts as a facade between your lib and BOs. This way you can pack your shared libraries clean and decoupled.