c# - 跨程序集和命名空间的依赖注入(inject)

Question

我正在处理一个我认为我理解其原因的 DI 问题，但我需要一些建议来解决。

我构建了一个与 Sql 对话的独立程序集(将此程序集称为 a)，以及另一个包含业务逻辑的程序集(将此程序集称为 b)。我在 b 程序集中为 db 类创建了一个接口(interface)。由于接口(interface)不是数据库程序集的一部分，我不需要对数据库项目的任何引用，如果我想在运行时运行单元测试而不是程序集，我可以加载对数据库程序集或 stub 的引用需要了解对方。

我可以在编译的业务逻辑库中编写代码，看起来像这样:(假设 a 和 b 是它们各自程序集中的 namespace )

 a.IDatabaseClass db_class = (a.IDatabase)new b.Database();

然而，当我尝试运行它时，我得到了一个无效的转换异常。我认为它编译是因为接口(interface)与类完美匹配，但在运行时失败，因为对象签名在数据库类的继承链中看不到 IDatabase。

在 C++ 中，您可以随心所欲地强制转换任何内容，但 C# 在强制转换对象指针方面稍微严格一些。即使该类具有所有正确的函数签名，它也会因为对象不匹配而崩溃。

现在我可以将 db 对象接口(interface)放在带有 db 对象的程序集中，但是业务逻辑需要引用 db 程序集。此外，这只会在未来造成复杂性，因为如果我在单元测试中编写一个 stub 数据库对象，我需要一个对数据库程序集的引用，只是为了我将在我的测试 stub 对象中使用的接口(interface)。这似乎并没有通过这样做来解开耦合......

我可以将所有接口(interface)放在第三个程序集中，该程序集是数据库程序集、业务逻辑和单元测试的父级。这就是解决循环依赖问题的方法。但是，这将 db 程序集与父程序集联系在一起，并使其在与其他项目一起使用时模块化程度大大降低。

我乐于接受有关如何设置每个程序集以使它们独立运行并可用于 DI 的建议。我想我可以将测试 stub 对象保存在与真实代码相同的程序集中，但这看起来很奇怪。

解决方案:下面的一个回复评论说我所追求的基本上是接口(interface)的鸭子类型。 C# 目前不支持鸭子类型，但我认为这可能是可能的，因为接口(interface)实现的行为方式类似于您可能称之为部分类指针(或者更准确地说，函数指针的集合)。我的实验告诉我并非如此，这就是原因。

因此，在 Redmond 将“更多野鸭”放入 c# 之前，看起来我们无法完全达到解耦程序集的最终优雅水平。

Answer 1

创建包含通用接口(interface)的引用库。这样，您将拥有一个包含所有实现不可知逻辑的公共(public)源。

我没有经验可以自信地将此作为绝对陈述，但我强烈怀疑当您谈论引用特定接口(interface)的各个类型及其行为方式时，耦合主要是一个问题。程序集没有那种会使耦合成为问题的特殊性。

编辑 1

让我修改和扩展。一个程序集必须引用另一个程序集，或者两者都必须引用一个公共(public)程序集。 C# 没有鸭子接口(interface)，如果那是一件事的话。

现在我认为最好的做法是将业务逻辑与外部接口(interface)隔离开来，因此如果您要执行任何操作，您应该将业务逻辑与数据库实现隔离开来。所以 DB/Application 程序集引用业务逻辑，而不是相反。

Here's more information about the dependency orientation .