清洁架构：什么是视图模型？

鲍勃叔叔在他的《清洁架构》一书中说，主持人应该将收到的数据放入他称为“视图模型”的东西中。

这与Model-View-ViewModel（MVVM）设计模式中的“ ViewModel”是一样的吗，还是简单的数据传输对象（DTO）？

如果不是简单的DTO，它与View有何关系？视图是否通过观察者关系从视图获取更新？

我的猜测是它更像是MVVM中的ViewModel，因为罗伯特·马丁（Robert Martin）在他的书的第23章中说：

[演示者]的工作是接受来自应用程序的数据并对其进行格式化以进行演示，以便View可以将其简单地移动到屏幕上。例如，如果应用程序希望在字段中显示日期，它将向Presenter传递Date对象。然后，Presenter会将数据格式化为适当的字符串，并将其放置在称为View模型的简单数据结构中，View可以在其中找到它。

这意味着View以某种方式连接到ViewModel，而不是简单地将其作为函数参数接收（例如DTO就是这种情况）。

我认为这是因为，如果您查看图像，演示者将使用视图模型，而不是视图。演示者同时使用输出边界和输出数据DTO。

如果既不是DTO也不是MVVM中的ViewModel，请详细说明它是什么。

这与Model-View-ViewModel（MVVM）设计模式中的“ ViewModel”是否一样

不。

那是这样的：

那有周期。鲍勃叔叔一直小心避免骑车。

相反，你有这个：

当然没有周期。但是，这让您想知道视图如何知道更新。稍后我们将解决这个问题。

还是简单的数据传输对象（DTO）？

要引用前一页中的Bob：

如果愿意，可以使用基本结构或简单的数据传输对象。或者，您可以将其打包到一个哈希图中，或将其构造到一个对象中。

清洁建筑p207

所以，当然，如果您愿意。

但我强烈怀疑什么是真正窃听你的是这个：

对UML的这种小小的滥用将源代码依赖的方向与控制流的方向进行了对比。在这里可以找到您问题的答案。

在使用关系中：

控制流的方向与源代码依赖项的方向相同。

在执行关系中：

控制流通常与源代码依赖项的方向相反。

这意味着您实际上正在查看此：

您应该能够看到控制流永远不会从Presenter传递到View。

这个怎么可能？这是什么意思？

这意味着视图要么具有自己的线程（这并不稀奇），要么（如@Euphoric所指出），控制流从此处未描述的其他内容进入视图。

如果是同一线程，则视图将知道何时可以读取视图模型。但是，如果是这种情况，并且视图是GUI，则当用户在等待数据库时将其移动时，将很难重新绘制屏幕。

如果视图具有自己的线程，则它具有自己的控制流。这意味着要实现此功能，视图将必须轮询视图模型以注意到更改。

由于演示者不知道该视图存在，并且该视图不知道该演示者存在，因此它们根本无法相互调用。他们不能互相殴打事件。可能发生的一切是Presenter将写入视图模型，而View将读取视图模型。每当有它的感觉。

根据此图，视图和演示者共享的唯一内容是对视图模型的了解。它只是一个数据结构。因此，不要指望它有任何行为。

这似乎是不可能的，但是即使视图模型很复杂也可以使它起作用。一个小的更新字段是视图必须轮询以检测更改的所有字段。

现在，您当然可以坚持使用观察者模式了，或者有一些框架性的东西可以使您看不到这个问题，但是请理解您不必这样做。

我在说明控制流程时有些有趣：

请注意，只要您发现流程与我之前定义的方向背道而驰，您所看到的就是调用返回。这个把戏不会帮助我们进入视图。好吧，除非我们先回到所谓的控制器。或者，您可以只更改设计，以便进入视图。这也解决了看起来像是数据访问及其接口的溜溜球问题的开始的问题。

除了这里唯一要学习的另一件事是，用例交互器几乎可以按其想要的任何顺序调用事物，只要它最后调用演示者即可。

我觉得这个问题太令人困惑了，因为我相信您对Martin的Clean Architecture和MVVM都误解了，所以需要花费大量文本和时间来正确解释问题。

首先要注意的是，您发布的图不完整。它仅显示“业务逻辑”，但缺少某种“编排器”，该“编排器”实际上使零件按正确的顺序移动。

Orchestrator的代码将非常简单

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

我相信我在他关于清洁建筑的演讲中听到了马丁对此的谈论。

要指出的另一件事是candied_orange关于缺少循环的说法是错误的。是的，循环在代码的体系结构中不存在（也不应该）。但是运行时实例之间的循环很常见，并且通常可以简化设计。

在MVVM中就是这种情况。在MVVM中，View依赖于ViewModel，并且ViewModel使用事件将其更改通知给View。这意味着在类的设计中，从View类到Model类仅存在依赖关系，但是在运行时，View和ViewModel实例之间存在周期性依赖关系。因此，不需要Orchestrator，因为ViewModel将提供View方法来确定何时进行自我更新。这就是为什么此图中的“通知”使用“弯曲”线而不是直接线的原因。这意味着View会观察ViewModel中的更改，而不是说ViewModel依赖于View。

您应该从Martin的Clean Architecture中获得的最重要的信息不是设计本身，而是如何处理依赖关系。他在演讲中提出的关键点之一是，当存在边界时，所有跨越该边界的代码依赖项都将在单个方向上跨越边界。在图中，该边界由双线表示。并且有许多通过接口（和）进行的依赖反转InputBoundary，可以修复代码的依赖方向。OutputBoundaryDataAccessInterface

相反ViewModel，“干净架构”中的DTO只是普通的，没有逻辑。这通过<DS>标签变得明显。这就是为什么orchestrator有必要的原因，因为View不知道何时运行它的逻辑。

如果我要将图“展平”为运行时的样子，它将如下所示：

因此，在运行时，依赖关系处于“错误”方向，但这很好。

我建议观看他关于清洁建筑的演讲，以更好地理解他的推理。