Question

我的问题：在应用程序内部，所有接口都在自己的dll中声明（例如，项目“接口”）。

在项目界面内部，也有许多类实现。

现在我需要在另一个项目中使用其中一个已实现的类并获得环依赖项，因为该项目也是项目接口中的引用。

那么，绕过这种环依赖的最佳方法是什么？这可能是应用程序设计中的一个重大错误吗？

示意图：

IBigInterface.cs（一个文件中的所有内容）：

interface ISomeInterfaceA
{
    void SomeFunctionA(ClassB x);    // ClassB from newProject.cs
    void SomeFunctionB();
}

//
// etc.
//
class ClassA
{
    //
    // Code
    //
}

newProject.cs（一个文件中的所有内容）：

class ClassB
{
    //
    // used in interfaces.dll
    //
}

class ClassC
{
    void SomeFunction(ClassA a)    // ClassA from IBigInterface.cs
    {
        //
        // do something
        //
    }
}

我想到的第一件事就是......像：

IBigInterface.cs：

interface ISomeInterfaceA
{
    void SomeFunctionA(IInterfaceB x);    // use interface instead of a class
    void SomeFunctionB();
}

interface IInterfaceB
{
    //
    // declarations
    //
}

class ClassA
{
    //
    // implementation
    //
}

newProject.cs：

class ClassB : IInterfaceB    // implementation of IInterfaceB
{
}

class ClassC
{
    void SomeFunction(ClassA a)
    {
        //
        // implementation
        //
    }
}

因此项目newProject不再是项目接口中的引用（尽管这意味着整个应用程序中的更改）。

P.S。：我继承了这个应用程序，所以在接口项目中实现类的想法不是我的想法:)。一般来说，我会为每个类创建一个文件（所以不要指向这个:)。

Answer 1

首先，将具体类和它们实现的接口组合到一个程序集中没有任何问题（尽管调用项目“interfaces”会有点奇怪）。

话虽如此，循环引用通常表示您已经过度模块化了代码：导致循环引用的部分属于一起，它们应该合并为一个程序集。

其他时候，循环引用只是一个类在错误层中的标志;该类需要完全移动到另一个程序集中（通常是从较低级别的基础结构程序集进入较高级别的程序集）。例如，ClassC可能真的属于引用“接口”程序集的另一个项目。

Answer 2

这正是Java 要求公共定义在他们自己的文件中的原因（但我认为你在这里得到了这个概念:)。

将纯接口和实现混合起来通常并不好（尽管有些情况可能会有用），如果将它们导出到DLL中，它肯定是一个麻烦制造者。

循环依赖意味着您的项目过于耦合而不同。这通常是设计不良的症状（ big ball of mud -like）。您应该处理删除耦合或将两个项目合并在一起。

Answer 3

如果你有一个特定的项目，如你所说，包含所有的接口，为什么不引入另一个包含“助手类”的项目，如ClassA？然后你的接口DLL和依赖于接口DLL的项目可以使用这些类。

Answer 4

我会尝试将几个项目中常见的类和接口分解为“公共”程序集（或类似程序），它与引用它的程序集没有依赖关系。

例如，Product等业务实体不必了解它如何持久保存到数据库或通过Web服务获取，而是做的服务组件Product的内容，例如IProductsRepository，需要知道Product是什么。因此，定义IProductsRepository的程序集（或命名空间）包含对Product所在的程序集（或命名空间）的引用，而不是相反。

接口dll中的类实现？

4 个答案: