【问题标题】:Plugin design, having circular dependency issues插件设计,存在循环依赖问题
【发布时间】:2011-01-04 09:23:19
【问题描述】:

我在 Project#1 中有一个 ecomm 应用程序。

我在 Project#2 中有一个引用 Project#1 的支付网关实现。它引用接口,以便将网关实现为合同。

现在我需要在 Project#1 中实际使用 Project#2 中的实现。

存在循环依赖,因此它不能按原样工作。

我该怎么办?我应该把接口分解成他们自己的项目吗?这似乎是最简单的方法。

关键是,如果我需要创建网关的另一个实现,它可以很容易地并入 Project#1。

【问题讨论】:

  • 你刚才不是用不同的方式问这个问题吗?-> stackoverflow.com/questions/2052579/circular-dependancies/…
  • mrblah 不珍惜你的时间。 -1 为 mrblah。事实上,mrblah 甚至懒得记下他之前的问题。如果 mrblah 的脑海里冒出一个问号,mrblah 会在这里问。 mrblah 不使用 google、javadoc 或任何这些。如果你愿意的话,mrblah 需要你的时间。

标签: c# visual-studio oop


【解决方案1】:

这是你的另一个问题的欺骗,但它至少有更多的细节。

如果项目 2 是项目 1 的插件,那么项目 1 在任何情况下都不应依赖项目 2。期间。

通过反射/MEF/等将项目 2 的程序集加载到项目 1 中。

【讨论】:

    【解决方案2】:

    将接口放在单独的库中通常是个好主意。它还确保您可以独立地改变和部署具体的实现。

    作为一般经验法则,当我设计时,我首先将接口与其消费者放在一起,然后如果需要,我会将它们移到单独的库中。

    据我了解您的描述,每个库中都有消费者,因此移动它们听起来是正确的方法。

    如果您发现这些接口完全不相关,您甚至可以考虑将它们放入两个不同的库

    【讨论】:

    • 你会用什么来作为接口的命名空间?
    • 啊,现在我需要在我的界面项目中引用枚举!
    • 命名空间:在很多情况下,你可以说接口代表了真实的模型(剩下的只是实现细节),所以你可能想相应地命名它。
    • 无论如何,枚举都是代码气味。将它们重构为多态类型。
    【解决方案3】:

    是的,将您的接口分解为另一个项目并从两个项目中引用该项目。这样,两者都依赖于抽象。

    【讨论】:

      【解决方案4】:

      是的。您应该将插件应该实现的接口(以及任何潜在的通用帮助代码)放在单独的程序集中。

      【讨论】:

        猜你喜欢
        • 2020-09-25
        • 1970-01-01
        • 1970-01-01
        • 2020-09-09
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多