清洁架构：服务器上的交互器逻辑

Question

我一直在玩 Clean Architecture 和 VIPER。

昨天有朋友问我为什么不把Interactor的逻辑放在服务器上，把处理后的数据同步到iOS客户端，而不是在Interactor上发送原始数据和处理。这将有很多好处，因为能够随意更改逻辑，在多个客户端（例如 iOS 和 Android）上复制的代码更少等等。

例如，假设我们有一个Profiles 列表和一个Posts 列表。每个帖子都有一张图片和一个 profileID。

假设我们想要一个显示所有帖子图像的表格视图的屏幕，当用户点击帖子时，我们会在单独的屏幕上显示相应的个人资料。在个人资料中，我们将显示该个人资料发布的名称和所有图片。

如果我们将逻辑留在客户端，我们会像这样同步数据：

{
    profiles: [
        {
            id: "...",
            name: "..."
        },
        ...
    ],
    posts: [
        {
            profileID: "...",
            imageURL: "..."
        }
    ]
}

然后我们将有一个 ShowPostsInteractor 将只返回所有帖子的数据和一个 ShowProfileInteractor 将过滤帖子的数据以仅从该配置文件中获取帖子，然后它将一些数据返回到像这样的视图：

{
    name: "...",
    imageURLs: ["...", ...]
}

第二种选择是将这个逻辑留在服务器上，在这种情况下，同步的数据将是：

{
    profiles: [
        {
            id: "...",
            name: "...",
            imageURLs: ["...", ...]
        },
        ...
    ],
    posts: [
        {
            profileID: "...",
            imageURL: "..."
        }
    ]
}

（注意在profiles中添加了imageURLs）

ShowProfileInteractor 只会将配置文件数据按原样传递给视图，因为它不再需要过滤帖子（这是由服务器完成的）。

当然，第二种方法复制了一些数据，但由于它只是字符串，所以这不是很相关。

我经常看到第一种方法。所以我的问题是，为什么我不采用第二种方法（在服务器上保留尽可能多的逻辑），并且可能从客户端删除所有交互器，让控制器直接访问网关，因为不会处理数据?

Answer 1

我可能错了，但我认为 Clean Architecture 在设计时并未考虑到移动或 SPA 应用。我一直认为它是一个很好的老式的以 Web 应用程序为中心的东西，交互器位于服务器端。

基本原理是架构应该是

独立于用户界面。 UI 可以轻松更改，无需更改其余部分 的系统。 Web UI 可以替换为控制台 UI，例如 例如，不改变业务规则

将交互器推到客户端会破坏这个目标，IMO。