在接口中使用模型时避免循环引用的最佳模式答案

【问题标题】：Best pattern for avoiding circular reference when using models in interfaces在接口中使用模型时避免循环引用的最佳模式
【发布时间】：2014-01-21 07:24:38
【问题描述】：

我经常得到类似于下面的代码，这会导致 Visual Studio 中的循环引用：

（这两个命名空间存在于不同的程序集中）

namespace Data
{
    public class DataContext : IDataContext
    {
        public IEnumerable<Person> GetAllPeople()
        {
            // Get all people here
        }
    }
}


namespace Interfaces
{
    public interface IDataContext
    {
        IEnumerable<Person> GetAllPeople();
    }
}

接口 (IDataContext) 和它的实现 (DataContext) 都依赖于名为 Person 的模型。

为了避免循环引用（Visual Studio 不允许），我认为有几个选择：

将模型移动到单独的Models 程序集中，并将其添加为对Interfaces 和Data 程序集的引用。
让Person 模型实现一个接口（例如IPerson），该接口将存在于Interfaces 程序集中，并在接口及其实现中使用它代替Person。

让一个单独的程序集包含几个小模型似乎很浪费，为只包含属性的模型创建接口也是如此。

最广泛接受的方法是什么？

【问题讨论】：

您是否需要将接口和实现放在单独的程序集中？您是否曾经部署过一个而不是另一个？如果没有，请将所有内容放在同一个程序集中。 codebetter.com/patricksmacchia/2008/12/08/…
这是我对非常相似的情况的看法：stackoverflow.com/a/20883444/122718 TL;DR：如果可能，合并程序集。
@IanNelson 不，但是在接口相互依赖的更复杂的项目中，我们发现将接口与实现一起存在可能会导致更多的循环引用问题。至少通过这种方式，接口程序集只需要依赖于自身（并且可能还依赖于模型程序集）。
在我看来，以这种方式物理分离类型有点过早分解。我会把所有东西都放在一个程序集中——模型、接口、实现、整个shebang。当然，我会适当地使用命名空间来进行 logical 分组。

标签： .net architecture interface

【解决方案1】：

为模型制作一个程序集，为服务接口制作一个程序集，为服务实现制作另一个程序集。

模型类应该只依赖于其他模型类。服务接口可能依赖于模型类。服务实现可能依赖于任何东西。

【讨论】：

那些建议的类型依赖规则是完全有效的，但可以通过命名空间和文件夹来实现。真的有必要创建单独的物理部署来强制执行这些做法吗？
我假设单独的物理部署是所需解决方案的一部分（也许是因为我通常工作的环境）。否则，你是对的。

【解决方案2】：

这两个选项都很好，选择一个取决于您的喜好：

如果您希望保留代码而不进行任何修改，而只是重新排列程序集，第一种方法是完美的：创建额外的程序集，无论它们多么小，都不会产生大到使它令人望而却步。
如果您更喜欢编程而不是接口，则第二种方法是完美的：您的代码将与实现类隔离，从而无法使用不打算使用的一两个方法。另外一个好处是，这还可以简化您的单元测试，因为用接口实现替换模拟对象是最简单的方法。

【讨论】：

【解决方案3】：

作为一个技巧，模型程序集不应包含对项目中任何其他程序集的引用。模型必须完全独立。

在模型程序集中创建所有类及其接口。然后将实现放在另一个程序集上。

【讨论】：