我正在努力避免循环依赖.我知道我需要使用接口隐藏实现,但是如何处理具有两个程序集的情况,其中每个程序集都需要从另一个程序集实例化类或从那里调用静态方法？
编辑:
我知道只需使用一个程序集就可以解决这个问题.由于以下原因,我们有多个:
让两个组件相互通信实际上只是我们以前遇到过循环依赖冲突的情况之一.它偶尔发生,当它发生时,我们需要弄清楚如何解决它 - 移动一些类 - 有时我们需要添加一个新的程序集.
现在我们有8-10个程序集,它看起来越多,它们被添加得越快:) - 例如,我们添加了一个使用自定义属性的通用功能 - 所以我们为属性添加了另一个程序集 - 只是万一我们将来不会发生冲突
这是要走的路吗？我真的觉得我们做的事情从根本上是错误的:)
我非常感谢你的意见.
Eri*_*bes 10
我会尝试将有问题的类型拉出到两个"父"程序集引用的第三个"公共"程序集中.
我会问,为什么你首先需要多个组件,但是,当它们彼此依赖时.程序集是部署单元,可以相互独立地进行版本控制.如果您不需要此功能,我只需将所有内容打包到一个程序集中即可完成.这增加了加速构建和简化部署的额外奖励.
请尝试为您的问题添加更多上下文 - 如果我们确切地知道您正在尝试做什么,也许我们可以提供一些细节.
编辑你的补充:要专门回答你关于是否有多个程序集的问题,请考虑一下:我曾经使用Visual Studio 2008在这样的代码库上工作,在解决方案中打开了大约20个单独的项目文件立刻.这20个项目都支持单个主要EXE的DLL.这些项目不与其他产品共享,也没有奇怪的版本要求.
使用这个解决方案是一场噩梦.Visual Studio花了5分钟来编译解决方案.使用MSBuild在命令行中编译花了2分钟.这使得渐进式变化成为挫折和痛苦的一种练习.由于所有项目都用于制作主要的可执行文件,因此没有任何项目可以卸载以加快编译速度,并且有一项执行授权要求将项目分解为单独的解决方案.
如果你最终得到这样的单一解决方案,那么当我说你和你的队友有一天会反抗时,请相信我...我的建议是将程序集分解成他们自己的解决方案,将任何可能组装的程序集合在一起改变了; 然后创建一个自定义生成任务,将最终的程序集复制到一个公共文件夹中,所有其他程序集都可以从中引用.
| 归档时间： |
|
| 查看次数： |
577 次 |
| 最近记录： |