循环依赖关系 - 再次

Question

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

编辑：

我明白，这可以通过使用单件组装固定。我们不止一个，原因如下：

• 我们的“系统”由几个组件组成。一个客户只能有一个组件，或者更多 - 所以我们做的是为不同的组件创建不同的组件。这是有道理的 - 为什么你会部署你不需要的东西 - 是不是浪费内存？
• 对于更多组件（大多数是帮助程序类）而言通用的东西已转到另一个程序集 - 再次，并非所有组件都需要所有帮助程序类，因此有更多程序集但是，这两个应用程序可以相互交谈 - 系统对于医生向护士发送系统请求，请求返回等等 - 这里是实际问题的地方

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

现在我们有像8-10组件，它看起来像你越有越快，他们会添加:) - 例如，我们添加使用自定义属性的通用功能 - 所以我们增加了一个装配只是属性 - 以防万一我们不冲突得到未来

这是要走的路？我真的感觉我们正在做的事情基本上是错误的:)

我真的很感激您的输入。

Answer 1

我会尽量拉违规类型伸到这两个“父”组件引用第三个“共同”集会。

我会问，为什么你在第一个地方需要多个组件，然而，当他们俩相依为命。组件是部署的单位，并且可以彼此分开版本化。如果你不需要这个功能，我会把所有东西都打包成一个单独的程序集并完成它。这增加了加速构建和简化部署的额外奖励。

请尝试为您的问题添加更多上下文 - 如果我们确切知道您正在尝试做什么，可能会提供一些详细信息。

编辑重新您添加：具体回答关于是否多个程序集是要走的路你的问题，考虑一下：我曾经在一个代码库这样与Visual Studio 2008，那里有大约20个单独的项目文件立即在解决方案中打开。这20个项目都支持单个主EXE的DLL。这些项目没有与其他产品共享，也没有奇怪的版本要求。

使用此解决方案是一场噩梦。花了5分钟的时间Visual Studio来编译解决方案。在命令行中用MSBuild编译需要2分钟。这使得增量变化成为挫折和痛苦的一种锻炼。由于所有这些项目都用于制作主要的可执行文件，因此它们都不能被卸载以加快编译速度，并且执行任务的目的是防止将项目分解为单独的解决方案。

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

Answer 2

你能把普通的东西放在自己的装配中吗？

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

为什么你有2个程序集？

有没有理由一切都不在一个程序集？

这些组件是如何连接的？只是通过参考或有WCF，等组件涉及？

我们已经给你最简单的答案，但也许还有更多比我们可以通过您简要说明一切。

Answer 3

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

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等等。

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