C#学习教程：跨程序集和命名空间的依赖注入我构建了一个与Sql对话的单独程序集（称为程序集a）和另一个包含业务逻辑的程序集（称为程序集b）。我在b程序集中为db类创建了一个接口。由于接口不是数据库程序集的一部分，我不需要对数据库项目的任何引用，如果我想在运行时而不是程序集运行单元测试，我可以加载对数据库程序集或存根的引用需要了解对方。我可以在一个业务逻辑库中编写代码，编译后看起来像这样：（假设a和b是它们各自程序集中的名称空间）a.IDatabaseClassdb_class=(a.IDatabase)newb.Database();但是当我试图运行它时，我得到了一个无效的转换异常。我认为它编译是因为接口与类完美匹配，但在运行时失败，因为对象签名在Database类的继承链中看不到IDatabase。在C++中，你可以抛出任何你想要的东西，但C#对构建对象指针有点严格。即使该类具有所有正确的函数签名，它也会因为对象不匹配而崩溃。现在我可以将db对象接口放在具有db对象的程序集中，但业务逻辑需要对db程序集的引用。此外，这只会造成复杂性，因为如果我在单元测试中编写存根数据库对象，我需要为将在测试存根对象中使用的接口引用数据库程序集。通过这样做，这似乎并没有解耦耦合……我可以将所有接口放在第三个程序集中，它是数据库程序集、业务逻辑和单元测试的父级。这就是解决循环依赖问题的方法。但是，这会将db程序集绑定到父程序集，并使其与其他项目一起使用时模块化程度大大降低。我乐于接受有关如何设置每个组件的建议，以便它们独立运行并可用于DI。我想我可以将测试存根对象保存在与真实代码相同的程序集中，但这看起来很奇怪。解决方案：下面的一个回复说我拍的基本上是界面的鸭子类型。C#目前不支持鸭子类型，但我认为这可能是可能的，因为接口实现的行为方式类似于您所谓的部分类指针（或者更准确地说，函数指针的集合）。我的实验告诉我并非如此，这就是原因。因此，在Redmond将“更多野鸭”放入c#之前，看起来我们无法完全实现最终优雅的解耦组件。创建包含常用接口的参考库。这样，您将拥有所有独立于实现的逻辑的公共源。我没有经验可以自信地将此作为明确的陈述，但我强烈怀疑当您谈论引用特定接口及其行为的个别类型时，耦合主要是一个问题。程序集不具有使耦合成为问题的相同特异性。编辑1让我修改和扩展。一个组件必须引用另一个组件，或者两者都必须引用一个公共组件。如果是这样的话，C#就没有duck接口。现在我认为最好的做法是将业务逻辑与外部接口隔离开来，所以如果你要做任何事情，你应该将业务逻辑与数据库实现隔离开来。所以DB/Application程序集引用业务逻辑，而不是相反。这里有更多关于依赖方向的信息。让客户端库(b)定义接口，并从服务器库(a)引用该库。根据依赖倒置原则，“客户端[...]拥有抽象接口”（APPP，第11章），因此没有理由将接口放在第三方库中。以上就是C#学习教程：跨程序集和命名空间的依赖注入分享的全部内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
