交互器或网关 - Bob 大叔的干净架构答案

【问题标题】：Interactor or Gateway - Uncle Bob's Clean Architecture交互器或网关 - Bob 大叔的干净架构
【发布时间】：2016-05-14 21:28:21
【问题描述】：

考虑Uncle Bob's Clean Architecture（或洋葱架构）

假设在我的应用程序中登录User，我收到一个深层链接网址"myapp://events/[event_id]"（例如通过短信）。

当我点击链接并在屏幕上显示Event 的信息时，我想加入那个Event。

流程如下：

用户点击链接
应用程序接收到 url 并提取 event_id
应用程序使用event_id 检索Event 的信息
应用将该信息保存在本地存储中
应用发送 POST 请求，让服务器知道有新用户（我）加入了活动
应用将检索到的Event的信息显示给用户

当应用发送 POST 请求加入活动时，它会发送 current_user 的 id，由后端处理（我使用 Parse 和 Facebook 登录）。这意味着所有用户身份验证都由Gateways 处理（使用 Parse，current_user 的 id 以PFUser 的形式出现，但在其他一些实现中它可能是String，所以它必须是由Gateway's 处理）。

我的问题是，整个交互（加入Event）应该由Gateway 还是由Interactor 处理？

对我来说，Interactor 应该处理所有这些过程似乎更合乎逻辑：
1. 使用event_id 检索信息
2. 将current_user 添加到Event
3. 调用Gateway在本地保存Event）
  
  但如果它由 Interactor 处理，则意味着此 Interactor 将需要有关 PFUser 的知识（如果我使用 Parse），如果我停止，将不得不更改它的实现使用 Parse（我会的）。
如果由Gateway 处理，则意味着Interactor 只会将join 调用转发给Gateway
(joinEventInteractor.join(eventId: String, callback: () -> ()) { eventGateway.join(eventId, callback: callback) })。

【问题讨论】：

标签： ios architecture onion-architecture

【解决方案1】：

您的网关不应该有任何业务逻辑，将您的逻辑保留在交互者内部并将网关仅作为边界处理，从它的名称开始，它应该只指向你的交互者，如果你添加任何逻辑，那么你就违反了单一责任原则

【讨论】：