存储库模式 - 我“需要”REST API 中的服务层吗？

Question

我提出这个问题是为了了解您对此事的看法，并看看我是否愚蠢或迂腐。

---

问题（tl；博士；）

当存储库层已经可以以更快的方式通过查询完成大部分事情（例如 FindUserByID）时，当服务必须以低效得多的方式手动完成所有这些事情时，我是否“需要”服务层（为了良好的实践）和超级手动方式？

描述（对于那些想了解我的动机的人）

所以，我一直在研究清洁架构，这很好，但不适用于 REST 架构。因为，Clean Architecture 实际上是由控制器层构成的，而 RPC 是处理控制器的层，而不是 REST。REST 处理资源。所以，我删除了“控制器”层，并且我也在考虑是否真的需要一个“服务”层。

所以 REST 需要“服务”和/或“存储库”。奇怪的是，我认为这两者重叠。我知道服务应该处理“业务规则”。但事情是这样的：

存储库可以对服务完成相同的工作，但存储库可以以更有效的方式完成相同的工作。

由于允许存储库与数据库直接通信，因此它们可以使用数据库查询（sql 或 nosql）。其写入效率更高、读取效率更高、性能也更高效。

服务方式：

比方说，您需要通过 ID 查找用户，然后通过姓名从他的好友列表中选择特定的朋友。

• 您从存储库中获取所有用户
• 您为所有用户创建一个循环
• 您设定一个条件，检查哪个用户拥有您想要的 ID
• 你为他朋友列表中的所有朋友制作了一个循环
• 你提出一个条件来检查朋友的名字

概括？喜欢 20-30 行代码和较慢的性能？

存储方式：

filter := bson.M{
    "_id": id,
    "friendlist.name": friendsName,
}
projection := bson.M{
    "friendlist": 1
}
friend, err := mongoDb.find(filter, projection)

概括？就像3-4行代码，和99%的数据库性能。

那么，“服务层”部分真的有必要吗？当存储库已经可以更有效地自行完成所有工作时，将其拆分为服务层和存储库层是否有任何真正的架构优势？

Answer 1

对于像“通过id检索用户”这样的小样本，也许不需要服务层。

然而，在更大的应用程序中，事情要复杂得多。一些例子：

• 用户存储被分解在一个单独的微服务中，需要通过 gRPC/HTTP 查询用户。
• 引入缓存层来缓存需要缓存失效的剩余资源（memcached、Redis 等）。
• Rest层需要写入多个版本，并进行重大更改，但数据库是相同的。
• 您引入事件总线来在系统中发生某些事情时触发事件。
• 您有大量的业务逻辑，需要不依赖于数据库连接的单元测试。

将事物分层分开将使测试、调试和更改变得更加容易。如果您遇到数据库查询性能不佳的情况，您可以通过构建更好的查询在存储库层中解决该问题，而无需担心其他部分。如果逻辑中存在错误，您可以在不依赖数据库的情况下修复它，只需构建一个单元测试用例并更新服务层即可完成。

对于一个具有简单用例的单人表演来说，分层是很烦人的。对于一个需要与许多不同的客户和多人一起工作的应用程序来说，这是必要的。

我不同意你对“服务方式”与“存储库方式”的描述。当然，您应该在存储库中提供优化的方法供服务使用，本质上是： Repository:GetSingleUserById 应该存在并在任何情况下进行优化。