使用多种解决方案在 C# 中创建接口时如何避免循环引用？答案

【问题标题】：How to avoid circular reference while creating interfaces in C# with multiple solutions?使用多种解决方案在 C# 中创建接口时如何避免循环引用？
【发布时间】：2014-02-25 14:07:40
【问题描述】：

我正在创建一个我想在多个新解决方案中使用的界面。让我们调用接口IBar和新解决方案的1ProjectX

在IBar 中，我定义了一个必须返回模型FooModel 的方法。

模型Foo 和接口类IBar 存在于数据解决方案中。因此，我将数据解决方案引用添加到 SolutionX，现在我可以轻松实现接口 (DataProject.Interfaces.IBar) 并返回 FooModel (DataProject.Models.FooModel )。

如何从Data层调用ProjectX中实现IBar接口的方法？？

如果我尝试将 ProjectX 引用添加到数据层解决方案，我会收到循环引用错误。我是接口新手，所以请原谅我的无知。

【问题讨论】：

标签： c# interface

【解决方案1】：

您不需要在 DataProject 中引用 SolutionX。您可以通过界面访问IBar 隐藏的功能。因此，在DataProject 中，您可能具有将IBar 作为参数的功能。

void Foo(IBar bar) {...}

【讨论】：

我明白你的意思。但是数据层需要决定调用哪个“模块”，并获得一个 FooModel 列表，对其应用一些过滤器，然后发送到我们的前端就可以正常工作了。那么如果我无法引用该特定类的结果，我该如何访问它呢？
在这种情况下，你需要一个依赖注入器。所以基本上，你设置DataProject 来使用上面的IBar 对象。然后使用注入IBar 实现的依赖注入器调用此方法。 en.wikipedia.org/wiki/Dependency_Injection
这是一个非常有趣的使用依赖注入器的解决方案。不幸的是，对于这个项目来说，它太多了，无法一次处理。但请记住这一点。我遵循 Henks 的建议，它已经运行良好。不过，仍然对其他答案持开放态度。

【解决方案2】：

您应该进行不同的设置，使IBar 方法返回IFooModel 的东西。

然后在单独的项目中定义IBar 和IFooModel。

接口用于分解循环引用，当你发现你正在创建循环时，就会出现问题。

【讨论】：

不，不一定。在某些时候，具体的类可能很有用。
是的，我有一种感觉，我需要将模型和类移动到自己的项目中。但是，如果我真的需要 FooModel，为什么要返回 IFooModel？
@Georg - 显然在某个时候。但如今，这种链接被深埋在一些 DI 层中。
我正在尝试向现有项目添加接口，以使其正常工作，而不是一堆代码。
返回IFooModel或FooModel的关键在于FooModel是否包含与Bar功能实现相关的任何信息。例如，Rectangle 不包含有关如何计算特定矩形的任何信息。因此，没有必要在界面后面隐藏矩形。