VIPER实体及其存储位置

如何解决VIPER实体及其存储位置

因此，我目前正在重建一个非常大的VIPER项目，并且其模块的大多数视图都是UITableViews。我在互联网上发现了几乎所有关于VIPER和UITableView的主题，但还有一件事仍然不清楚-我应该在哪里存储viewmodel，我真的需要它们吗？

例如-我有一个带有UITableViewController的简单毒蛇模块，我需要显示项目列表。 Interactor使用一些我解码为Codable结构的项目数组来获取JSON。然后，我通过InteractorOutput协议将此结构的数组从交互器推回到演示者。现在我有两个问题：

我是否必须使用其他数据模型（viewmodel）在视图中显示数据，还是可以使用已有的Codable Struct？
我应该将viewmodels存储在哪里？在Presenter内部，像这样从View请求数据：presenter.getData（forItemAt：indexPath.row）。还是我必须将viewmodels数组推入View并要求View显示它们？

解决方法

如https://TheSwiftDev.com/the-ultimate-viper-architecture-tutorial中所述，

UITableView 被隔离在视图区域内。
本身没有视图模型。其他架构的这个目的在 VIPER 中的划分不同，主要是在演示者区域，但没有对视图本身的公开了解（而是专注于用例的业务规则）。 VIPER 视图区域中的 UI 视图至少符合一个用例。从交互器区域（获取/存储）通过展示器区域（业务/应用程序域规则执行/处理）到查看区域（反之亦然）的数据在不直接了解特定操作系统的特定 UI 构造及其参数需求的情况下进行建模.当跨越 VIPER 区域时，实体被建模为可移植（即使尚未）到其他操作系统上的其他 UI。例如，在为 iOS/iPadOS/WatchOS 应用程序开发时，事件和数据/实体的区域间交换已完成，因此它们至少不知道 iOS/iPadOS/WatchOS UI 视图构造及其参数的特性，因此 4在同一应用程序的 MacOS 版本中，除视图和路由器 {interactor、presenter、entities} 以外的 VIPER 区域保持不变。小心（例如，所有非 Apple 平台上的 Swift；OpenCombine 框架而不是 Apple Combine 框架用于区域间效应反应数据流）这个概念也可以外推到应用程序的 Android 和 UWP 版本，但以 Apple 为中心的部分交互器区域也需要更改，这就是将每个主题隔离在一个区域中的原因，以便它不会污染其他区域（如大规模视图控制器架构所示）。
演示者区域应该完全不了解或访问 UITableView 结构。因此，presenter.getData(forItemAt: indexPath.row) 将替换为处理实体集合的演示者，其中实体集合可能会在视图区域中作为 UITableView 在 iOS/iPadOS/WatchOS 上获得 UI 查看，但获得 UI-在 MacOS、Android 或 UWP 上的看法完全不同，也许根本不是表格，而是作为路由器导航的 2D 图标/选择数组。您的“或者 [do] 我 [需要] 必须将 ViewModel 数组推送到 View 并要求 View 显示它们？”几乎是一针见血，除了 VIPER 架构没有在那里使用术语 ViewModel；改用实体一词（即，与 UI 和操作系统分离的纯粹应用域实体）。
Codable 是 Apple JSON 处理中的一个接口。因此，它需要被隔离在交互器区域内，以便移植到非 Apple 操作系统上（真实的或预期的良好的心理卫生）。来自（和输出到）JSON 交互器的输入需要在纯应用程序域的实体中表达，而无需了解不可移植的框架，例如 SwiftUI 中的 Codable。需要将表示 JSON 处理输出的以 Apple 为中心的方式转换为表示这些等效实体的纯应用程序域方式。