循环依赖 - 再次

时间:2010-01-12 19:39:39

标签: c# .net

我正在努力避免循环依赖。我知道我需要用接口隐藏实现,但是我如何处理两个程序集的情况,其中每个程序集都需要从另一个程序集实例化类或从那里调用静态方法?

修改

我知道只需使用一个程序集就可以解决这个问题。由于以下原因,我们有多个:

  • 我们的“系统”由几个组成部分组成。客户只能拥有一个或多个组件 - 所以我们所做的就是为不同的组件创建了不同的组件。这有点道理 - 你为什么要部署你不需要的东西 - 这不是浪费内存吗?
  • 更多组件常见的东西,主要是辅助类,转到另一个程序集 - 同样不是所有组件都需要所有辅助类,因此有更多的程序集
  • 然而,这两个应用程序可以相互通信 - 医生系统向护士发送系统请求,请求返回等等 - 这就是实际问题所在

让两个组件相互通信实际上只是我们之前遇到过循环依赖冲突的情况之一。它偶尔发生,当它发生时,我们需要弄清楚如何解决它 - 移动一些类 - 有时我们需要添加一个新的程序集。

现在我们有8-10个程序集,它看起来越多,它们被添加得越快:) - 例如,我们添加了一个使用自定义属性的通用功能 - 所以我们添加了另一个程序集属性 - 以防我们以后不会发生冲突

这是要走的路吗?我真的觉得我们正在做一些根本错误的事情:)

我非常感谢您的意见。

3 个答案:

答案 0 :(得分:10)

我会尝试将有问题的类型拉出到两个“父”程序集引用的第三个“通用”程序集中。

我会问,为什么你首先需要多个组件,但是,当它们彼此依赖时。程序集是部署单元,可以相互独立地进行版本控制。如果您不需要此功能,我只需将所有内容打包到一个程序集中即可完成。这增加了加速构建和简化部署的额外奖励。

请尝试为您的问题添加更多背景信息 - 如果我们确切知道您正在尝试做什么,也许我们可以提供一些细节。

编辑你的新增内容:要专门回答你关于是否有多个程序集的问题,请考虑一下:我曾经使用Visual Studio 2008在这样的代码库上工作过,那里有在解决方案中同时打开了大约20个单独的项目文件。这20个项目都支持单个主要EXE的DLL。这些项目没有与其他产品共享,也没有奇怪的版本要求。

使用此解决方案是一场噩梦。 Visual Studio花了5分钟来编译解决方案。使用MSBuild在命令行中编译花了2分钟。这使得渐进式变化成为挫折和痛苦的一种练习。由于所有项目都用于制作主要的可执行文件,因此没有任何项目可以卸载以加快编译速度,并且有一项执行授权要求将项目分解为单独的解决方案。

如果你最终得到这样的单一解决方案,那么当我说你和你的队友有一天会反抗时,请相信我...我的建议是将装配分解成他们自己的解决方案,将所有装配组合在一起可能会一起改变;然后创建一个自定义构建任务,将最终程序集复制到一个公共文件夹中,所有其他程序集都可以从该文件夹中进行引用。

答案 1 :(得分:3)

你能把常见的东西放在自己的装配中吗?

我同意一位评论者的意见,我们可能需要更多信息。

为什么你有两个装配?

有没有理由一切都不在一个集会中?

这些组件是如何连接的?仅通过引用或是否涉及WCF等组件?

我们已经为您提供了最简单的答案,但也许还有比我们的简要描述更多的答案。

答案 2 :(得分:1)

避免它的一种方法是使用代理/业务结构。

AssemblyA.Proxy - 包含两个类:一个接口(让我们称之为IServices),另一个类负责调用 AssemblyA.Business 方法。

AssemblyA.Business - 包含一个类,它实现在 IServices 上声明的方法。

AssemblyB.Proxy - 类似于AssemblyA.Proxy

AssemblyB.Business - 类似于AssemblyA.Business

这样,每个代理组件只会引用它们应该使用的业务逻辑。 AssemblyA.Proxy将引用AssemblyA.Business; AssemblyB.Proxy将引用AssemblyB.Business。 AssemblyA.Business将引用AssemblyB.Proxy,依此类推。

不知道它是否清楚但希望它有所帮助。