因此，我目前正在将一个非常大的项目重构为VIPER架构，其模块的大多数视图都是UITableViews。我在互联网上发现了几乎所有关于VIPER和UITableView的话题，但有一点仍然不清楚：我应该把ViewModel存储在哪里，我真的需要它们吗？
例如，我有一个带有UITableViewController的简单VIPER模块，我需要显示项目列表。交互程序获取带有一些项目数组的JSON，我将这些项目解码为可编码结构。然后，我通过交互输出协议将这个结构的数组从交互程序推回到演示程序。现在我有两个问题：
-
我必须使用另一个数据模型(ViewModel(来在视图中显示数据吗？或者我可以使用现有的可编码结构吗？
-
我应该将ViewModels存储在哪里？在Presenter内部，从视图中请求数据，如下所示：present.getData(forItemAt:indexPath.row(。或者我必须将ViewModel数组推送到View，并要求View显示它们？
如中所述https://TheSwiftDev.com/the-ultimate-viper-architecture-tutorial，
- UITableView在视图区域内被隔离
- 没有视图模型本身。其他架构的目的在VIPER中有不同的划分，主要在演示者区域，但对视图本身没有公开的了解(而是专注于用例的业务规则(。VIPER视图区域中的UI视图至少符合一个用例。从交互程序区域(获取/存储(通过演示程序区域(业务/应用程序域规则执行/处理(流到查看区域(反之亦然(的数据是在不直接了解特定操作系统的特定UI构造的情况下建模的；它们的参数需求。当跨越VIPER区域时，实体被建模为可移植(即使还没有(到其他操作系统上的其他UI。例如，在为iOS/iPadOS/WatchOS应用程序开发时，区域间的事件交换&数据/实体被完成，使得它们至少不知道iOS/iPadOS/WatchOS UI视图构造的特性&以使得除了视图&路由器{interator，presentar，entities}在同一应用程序的MacOS版本中保持不变。小心(例如，Swift在所有非苹果平台上；OpenCombine框架而不是Apple Combine框架用于区域间效应反应性数据流(，这个概念可以外推到Android和Android；UWP版本的应用程序也是如此，但互动器区域中以苹果为中心的部分也需要更改，这就是隔离区域中每个主题的原因，这样它就不会污染其他区域(如Massive View Controller架构所示(
- 演示者区域应该根本不了解或访问UITableView构造。因此，presentar.getData(forItemAt:indexPath.row(将被处理实体集合的presentar所取代，在该集合中，实体集合可能会在iOS/iPadOS/WatchOS上以UITableView的形式在视图区域中查看UI，但在MacOS、Android或UWP上则会以完全不同的方式查看UI，可能根本不是作为表，而是作为要导航的路由器的图标/选项的2D阵列。你的"或者我[需要]把ViewModel的数组推到View并让View展示它们吗？"几乎一针见血，只是VIPER架构在那里没有使用ViewModel这个术语；而是使用实体一词(即脱离UI和OS的纯应用程序域实体(
- Codable是苹果JSON处理中的一个接口。因此，它需要在交互区内隔离，以便于非苹果操作系统的可移植性(真实的或预期的良好心理卫生(。JSON交互程序的输入(和输出(需要在纯应用程序域的实体中表达，而不知道SwiftUI中的Codable等不可移植框架。需要从以苹果为中心的JSON处理输出表示方式转换为纯应用程序域的等效实体表示方式