干净的架构：框架之间的序列流

Question

我一直在努力从博客、文章和视频中了解更多关于 Uncle Bob 的 Clean Architecture。

如果我要在此架构中使用数据库，那么 UI（作为 Web 或表单等框架）应该了解数据库的哪些信息？或者更一般地说，数据应该如何在同一层的两个或多个pieces/parts之间流动？

例如，UI 会与我的适配器/网关对话以与业务实体进行交互。对于 Read/Write，我可以看到 UI 可以调用任何可以访问数据库并传入适配器/网关的 class/classes，以便它可以与商业实体。

    public class SomeUI
    {
        public static void Main(string[] args)
        {
            SomeAdapter adapter = new SomeAdapter();
            SomeDataAccess db = new SomeDataAccess();
            db.Save(adapter);
        }
    }

    public class SomeDataAccess
    {
        public void Save(SomeAdapter adapter)
        {
            //Interact with database
        }
    }

    public class SomeAdapter
    {
        //properties
    }

许多文章几乎与这篇文章不同 (https://subvisual.co/blog/posts/20-clean-architecture)。我还没有找到一篇很好的文章来介绍同一层中的部分应该如何相互协作。因此，引用该内容的文章将是一个可以接受的答案。

这似乎没有违反依赖规则，但感觉我做错了什么，因为我在 UI 和数据库之间建立了依赖关系。我相信我可能对这个概念想得太多了，我相信这可能是因为努力学习 3 层架构 (UI -> BLL -> DAL)。

Answer 1

我一直在对其他清洁架构示例进行更多研究。

(source).

从上图中可以看出，App（业务实体和用例）与 Delivery（外部：UI）来回对话。 Delivery 用于与外部（外部：DAL）对话。

Delivery is where you implement the delivery mechanism of your application itself. Delivery is where your app is integrated with external data sources and shown to the user. This means in simplest terms the UI, but it also means creating concrete versions of the external objects, such as data jacks, and also calling the actions of the app itself. -Retro Mocha

所以，这让我相信顶部的代码示例是有效的，但我仍然愿意听听是否还有其他人可以提供更多答案。

Answer 2

你问：

If I were to use a database in this architecture, then what should the UI (as a framework such as web or form) know about the database? Or more generally, how should data flow between two or more pieces/parts that are in the same layer?

在Clean Architecture中没有UI组件这样的术语。在简洁架构术语中，UI将是表示层或交付机制，分解为以下组件：

视图模型生成器（或presenter使用Uncle Bob的术语），负责封装业务规则UI。这应该访问业务模型以便从中生成 视图模型。业务模型由其调用者 interactor[=101] 传递给 interactor response 对象内的 presenter 方法=].

视图模型，它保存视图的数据并间接传递给视图例如通过一个事件。

dumb view现在与领域模型和所有层解耦，显示视图模型的数据。

以这种方式分解可确保更好的可测试性、更好的 SRP 以及与应用程序、域和基础架构层的更多解耦。

因此您的表示层应该对基础设施层一无所知。

也许您对使用某种 Web 表单 component/library 的示例感到困惑？这种组件提出了相互关联的功能，每个功能都与几个架构层相关：域、应用程序和表示……因此 Web Form 组件特别精致，无法在 Clean Architecture 中令人满意地适应。由于这种不灵活，我仍在努力寻找在我的 Clean Architecture 实现中集成 Web Form 组件的最佳方法。 .

最后，为了说清楚，你说：

For example, The UI would talk to my adapter(s)/gateway(s) to interact with the business entities. To Read/Write, I can see that the UI could call whatever class/classes that can access the database and pass in the adapter(s)/gateway(s), so that it can interact with the business entities.

UI 不负责与您的实体互动，但顾名思义，interactor的职责（interactor = use case）。 Interactor是对应用业务规则的封装，代表应用层。他们可以通过 Entity Gateway 对您的实体进行 CRUD，这是您到基础设施层的适配器，可以是 ORM、REST API 或其他任何...

编辑 #1:

因为这里有一张价值一千字的图片是 Uncle Bob 的 UML class 图，表示 Clean Architecture 的结构（以及相关组件之间的数据流） :

编辑 #2:

在我看来，您在 简洁架构 中对控制流的表示有些颠倒。参考上图和Bob大叔的类比：

If you don't want your code to be dependent of a thing, make this thing a plugin.

（换句话说，让那个东西成为你想要独立于它的代码的客户端。）

在简洁架构中，您需要表示层，或者更具体地说，交付机制（Controller + Presenter + ViewModel + View) 成为业务层的插件（由沟通渠道边界).

干净的架构：框架之间的序列流

Clean Architecture: Sequence Flow Among Frameworks

database

user-interface

frameworks

clean-architecture