Ios 干净的体系结构：服务器上的交互逻辑

我一直在和他玩

昨天一位朋友问我，为什么不把

交互器

逻辑放在服务器上，把处理过的数据同步到iOS客户端，而不是在

交互器

上发送原始数据和处理。这将有很多好处，因为可以随意更改逻辑，减少在多个客户端（例如iOS和Android）上复制的代码，等等

例如，假设我们有一个

Profile

s列表和一个

Post

s列表。每个帖子都有一个图像和一个profileID

假设我们想要一个屏幕显示一个包含所有帖子图像的表视图，当用户点击一篇帖子时，我们在一个单独的屏幕上显示相应的配置文件。在配置文件中，我们将显示名称和该配置文件发布的所有图像

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

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

然后我们会有一个

showPostsInTerractor

，它只会返回所有帖子的数据，还有一个

showProfileInteractitor

，它会过滤帖子的数据，只从该配置文件中获取帖子，然后它会将一些数据返回到视图，如：

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

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

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

（注意在

配置文件中添加了
图像URL
）

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

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

我经常看到第一种方法。所以我的问题是，为什么我不采取第二种方法（在服务器上保留尽可能多的逻辑），也许从客户端删除所有的交互程序，让控制器直接访问网关，因为这样就不会处理数据了？
我可能错了，但我不认为Clean架构设计时考虑到了移动或水疗应用程序。我一直认为它是一种以web应用程序为中心、交互器位于服务器端的好方法

其基本原理是架构应该是

独立于用户界面。UI可以很容易地更改，而无需更改其余部分
这是系统的一部分。例如，Web UI可以替换为控制台UI
例如，在不更改业务规则的情况下

在我看来，将交互程序推到客户端将无法实现这一目标。
所以您要实现我给出的第二个示例？另外，对于干净的移动架构，请看VIPER（），好的，因此他们似乎将服务器视为另一个数据存储。这有点道理。我仍然不是100%相信干净的架构适合移动设备
可以在iOS应用程序或控制台应用程序中使用相同的交互器，如VIPER中所述，与用另一个
替换UI不完全相同。一般来说，与web应用程序相比，在移动应用程序中推迟架构决策的好处要小得多，IMO。关于你的问题，我会说是的，特别是如果你计划添加更多移动平台的话。用多种客户机语言编写interactor会降低其可维护性。但是，您愿意在服务器和客户机上进行多少处理也是等式的一个重要部分。我不知道VIPER是否适合将交互程序移动到服务器端。