存储库模式 - 我 "need" 是 REST API 中的服务层吗？
Repository pattern - Do I "need" a service layer in REST API?
我提出这个问题是想听听大家对这件事的看法，看看我是不是傻了还是学究气了。
问题 (tl;dr;)
当存储库层已经可以通过查询以更快的方式完成大部分事情（如 FindUserByID）时，我是否 "need" 服务层（良好实践），而服务必须完成所有这些以更加低效和超级手动的方式手动操作？
描述（对于那些想了解我的动机的人）
所以，我一直在处理 Clean Architecture，这很棒，但不适用于 REST 架构。因为，Clean Architecture 实际上是由控制器层构成的，而 RPC 是处理控制器的层，而不是 REST。 REST 处理资源。 所以，我删除了"controller"层，我也在想我是否真的需要一个"service"层。
所以REST需要"services"and/or"repositories"。奇怪的是，我认为这两者重叠。我知道 服务 应该 处理 "business rules"。但事情是这样的：
存储库可以用服务做同样的工作，但是存储库可以用更有效的方式做同样的工作。
由于允许存储库与数据库直接通信，它们可以使用数据库查询（sql，或者没有sql）。 写入效率更高，读取效率更高，性能效率更高。
服务方式：
比如说，你需要通过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%的数据库性能。
那么，"Service layer" 部分真的有必要吗？当存储库本身已经可以更有效地完成所有工作时，将其拆分为服务层和存储库层是否有任何真正的架构优势？
Do I "need" the service layer (for good practice) when the repository layer already can do most of the things (like FindUserByID) with queries in a faster way, when the service has to do all these things manually in a much more inefficient and super manual way?
不，你不知道。通过不必要的层路由您的数据以获得体系结构点不会为您提供更易于维护或更便宜的代码。
另请参阅命令查询责任分离 (CQRS)。
对于像"retrieve user by id"这样的小样本，也许不需要服务层。
但是，在较大的应用程序中 - 事情要复杂得多。一些例子：
- 用户存储在一个单独的微服务中被分解，需要为超过 gRPC/HTTP 的用户查询。
- 引入缓存层来缓存需要缓存失效的剩余资源（memcached、Redis 等）。
- Rest-layer需要写成几个版本，breaking changes，但是数据库是一样的。
- 当系统中发生某些事情时，您引入事件总线来触发事件。
- 您有大量的业务逻辑需要不依赖于数据库连接的单元测试。
将事物分层放置将使测试、调试和更改变得更加容易。如果您遇到数据库查询性能不佳的情况，您可以通过构建更好的查询在存储库层中解决该问题，而无需担心其他部分。如果逻辑上有bug，不用依赖数据库就可以修复，只需要构建一个单元测试用例，更新服务层就可以了。
对于一个简单用例的单人节目来说，分层很烦人。对于一个应该与许多不同的客户和多人一起工作很长时间的应用程序来说，这是必需的。
而且我不同意你对 "the service way" 与 "repository way" 的描述。您当然应该在存储库中提供优化的方法供服务使用，本质上：Repository:GetSingleUserById 应该存在并且在任何情况下都应该进行优化。
我提出这个问题是想听听大家对这件事的看法，看看我是不是傻了还是学究气了。
问题 (tl;dr;)
当存储库层已经可以通过查询以更快的方式完成大部分事情（如 FindUserByID）时，我是否 "need" 服务层（良好实践），而服务必须完成所有这些以更加低效和超级手动的方式手动操作？
描述（对于那些想了解我的动机的人）
所以，我一直在处理 Clean Architecture，这很棒，但不适用于 REST 架构。因为，Clean Architecture 实际上是由控制器层构成的，而 RPC 是处理控制器的层，而不是 REST。 REST 处理资源。 所以，我删除了"controller"层，我也在想我是否真的需要一个"service"层。
所以REST需要"services"and/or"repositories"。奇怪的是，我认为这两者重叠。我知道 服务 应该 处理 "business rules"。但事情是这样的：
存储库可以用服务做同样的工作，但是存储库可以用更有效的方式做同样的工作。
由于允许存储库与数据库直接通信，它们可以使用数据库查询（sql，或者没有sql）。 写入效率更高，读取效率更高，性能效率更高。
服务方式：
比如说，你需要通过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%的数据库性能。
那么，"Service layer" 部分真的有必要吗？当存储库本身已经可以更有效地完成所有工作时，将其拆分为服务层和存储库层是否有任何真正的架构优势？
Do I "need" the service layer (for good practice) when the repository layer already can do most of the things (like FindUserByID) with queries in a faster way, when the service has to do all these things manually in a much more inefficient and super manual way?
不，你不知道。通过不必要的层路由您的数据以获得体系结构点不会为您提供更易于维护或更便宜的代码。
另请参阅命令查询责任分离 (CQRS)。
对于像"retrieve user by id"这样的小样本，也许不需要服务层。
但是，在较大的应用程序中 - 事情要复杂得多。一些例子：
- 用户存储在一个单独的微服务中被分解，需要为超过 gRPC/HTTP 的用户查询。
- 引入缓存层来缓存需要缓存失效的剩余资源（memcached、Redis 等）。
- Rest-layer需要写成几个版本，breaking changes，但是数据库是一样的。
- 当系统中发生某些事情时，您引入事件总线来触发事件。
- 您有大量的业务逻辑需要不依赖于数据库连接的单元测试。
将事物分层放置将使测试、调试和更改变得更加容易。如果您遇到数据库查询性能不佳的情况，您可以通过构建更好的查询在存储库层中解决该问题，而无需担心其他部分。如果逻辑上有bug，不用依赖数据库就可以修复，只需要构建一个单元测试用例，更新服务层就可以了。
对于一个简单用例的单人节目来说，分层很烦人。对于一个应该与许多不同的客户和多人一起工作很长时间的应用程序来说，这是必需的。
而且我不同意你对 "the service way" 与 "repository way" 的描述。您当然应该在存储库中提供优化的方法供服务使用，本质上：Repository:GetSingleUserById 应该存在并且在任何情况下都应该进行优化。