c# - 架构:依赖注入(inject)、松散耦合的程序集、实现隐藏

Question

我一直在从事一个个人项目，除了为自己制作一些有用的东西外，我还尝试将其作为一种继续寻找和学习建筑类(class)的方式。有一次这样的教训就像一只科迪亚克熊出现在自行车道中间，我一直在与它作斗争。

这个问题本质上是依赖注入(inject)、程序集解耦和实现隐藏(即使用内部类实现我的公共(public)接口(interface))交汇处的问题混合体。

在我的工作中，我通常发现应用程序的各个层都有自己的接口(interface)，它们公开公开，但在内部实现。每个程序集的 DI 代码将内部类注册到公共(public)接口(interface)。此技术可防止外部程序集更新实现类的实例。但是，我在构建此解决方案时阅读的一些书籍反对这一点。与我之前的想法相冲突的主要事情与 DI 组合根以及应该在何处保留给定实现的接口(interface)有关。如果我将依赖项注册移动到单个全局组合根(如 Mark Seemann 所建议的那样)，那么我就可以摆脱每个程序集都必须运行其自己的依赖项注册。然而，缺点是实现类必须是公共(public)的(允许任何程序集实例化它们)。至于解耦程序集，Martin Fowler 指示将接口(interface)放在项目中，其中包含使用接口(interface)的代码，而不是实现接口(interface)的代码。作为示例，这是他提供的图表，作为对比，我通常会如何实现相同解决方案的图表(好吧，这些并不完全相同；请注意箭头并注意实现箭头何时交叉组装边界而不是合成箭头)。

马丁风格

我通常看到的

我立即看到了 Martin 图中的优势，它允许将较低的程序集换成另一个，因为它有一个类在其上层实现接口(interface)。然而，我也看到了这个看似主要的缺点:如果你想从上层换出程序集，你实际上是“窃取”了下层正在实现的接口(interface)。

稍微考虑一下后，我决定在两个方向上完全解耦的最佳方法是让接口(interface)在它们自己的程序集中指定层之间的契约。考虑这个更新的图表:

这是疯了吗？是正确的吗？在我看来，这似乎解决了接口(interface)隔离的问题。但是，它并没有解决无法将实现类隐藏为内部的问题。那里有什么合理的事情可以做吗？我不应该为此担心吗？

我正在考虑的一个解决方案是让每一层都实现代理层的接口(interface)两次；一次是公共(public)课，一次是内部课。这样，公共(public)类就可以仅包装/装饰内部类，如下所示:

一些代码可能是这样的:

namespace MechanismProxy // Simulates Mechanism Proxy Assembly
{
    public interface IMechanism
    {
        void DoStuff();
    }
}

namespace MechanismImpl // Simulates Mechanism Assembly
{
    using MechanismProxy;

    // This class would be registered to IMechanism in the DI container
    public class Mechanism : IMechanism
    {
        private readonly IMechanism _internalMechanism = new InternalMechanism();

        public void DoStuff()
        {
            _internalMechanism.DoStuff();
        }
    }

    internal class InternalMechanism : IMechanism
    {
        public void DoStuff()
        {
            // Do whatever
        }
    }
}

...当然，我仍然需要解决一些关于构造函数注入(inject)和将注入(inject)公共(public)类的依赖项传递给内部类的问题。还有一个问题是外部程序集可能会更新公共(public)机制......我需要一种方法来确保只有 DI 容器可以做到这一点......我想如果我能弄清楚，我什至不需要内部版本。不管怎样，如果有人能帮助我理解如何克服这些架构问题，我将不胜感激。

Answer 1

However, the downside is that the implementation classes have to be public (allowing any assembly to instantiate them).

除非您正在构建一个可重用的库(在 NuGet 上发布并被您无法控制的其他代码库使用)，否则通常没有理由将类设为内部类。尤其是当您针对接口(interface)编程时，应用程序中唯一依赖于这些类的地方就是 Composition Root。

另请注意，如果您将抽象移动到不同的库，并让使用程序集和执行程序集都依赖于该程序集，则这些程序集不必相互依赖。这意味着这些类是公共(public)类还是内部类根本无关紧要。

然而几乎不需要这种级别的分离(将接口(interface)放在其自己的程序集中)。最后，一切都与部署期间所需的粒度和应用程序的大小有关。

As for decoupling assemblies, Martin Fowler instructs to put interfaces in the project with the code that uses the interface, not the one that implements it.

这是 Dependency Inversion Principle ，其中指出:

In a direct application of dependency inversion, the abstracts are owned by the upper/policy layers