存储库模式-我是否“需要”RESTAPI中的服务层？

我问这个问题是想听听你对这件事的看法，看看我是不是在装傻还是在迂腐

问题tl；博士 当存储库层已经能够以更快的方式使用查询完成大多数事情（如FindUserByID）时，当服务必须以更低效和超级手动的方式手动完成所有这些事情时，我是否需要服务层来实现良好的实践

对那些想了解我动机的人的描述 所以，我一直在处理干净的体系结构，这很好，但不适用于REST体系结构。因为，干净的体系结构实际上是由一个控制器层组成的，RPC是处理控制器的，而不是REST。REST处理资源。因此，我删除了控制器层，我也在考虑是否真的需要一个服务层

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

存储库可以对服务执行相同的任务，但存储库可以以更高效的方式执行相同的任务。 由于允许存储库与数据库直接通信，所以它们可以使用sql或nosql数据库查询。写的效率更高，读的效率更高，性能更高

服务方式： 比如说，你需要通过他的ID找到一个用户，然后根据他的名字从他的好友列表中选择一个特定的朋友

您可以从存储库获取所有用户 为所有用户创建一个循环 您可以设置一个条件，检查哪个用户具有您想要的ID 你在朋友名单上给他所有的朋友打个循环 你设定一个条件来检查朋友的名字 总结？比如20-30行代码和较慢的性能

存储库方式： 过滤器：=bson.M{ _id:id， FriendsList.name:friendsName， } 投影：=bson.M{ 友人名单：1 } friend，err:=mongoDb.findfilter，投影 总结？比如3-4行代码，99%的数据库性能

那么，是否真的需要服务层部分呢？当存储库可以更高效地自己完成所有工作时，将其拆分为服务层和存储库层是否有真正的体系结构优势

当存储库层已经能够以更快的方式使用查询完成大多数事情（如FindUserByID）时，当服务必须以更低效和超级手动的方式手动完成所有这些事情时，我是否需要服务层来实现良好的实践

不，你没有。通过不必要的层路由数据以获得体系结构分数并不能使代码更易于维护或交付成本更低

---

另请参见命令查询CQR。

有关按id检索用户这样的小示例，可能不需要服务层

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

用户存储在一个单独的微服务中，需要通过gRPC/HTTP查询用户。 引入缓存层来缓存需要缓存失效的rest资源memcached、Redis等。 Rest层需要写入多个版本，并进行中断更改，但数据库是相同的。 当系统中发生某些事情时，引入事件总线来触发事件。 您有大量的业务逻辑，需要不依赖于数据库连接的单元测试。 将事物分层将使测试、调试和更改更加容易。如果数据库查询的性能不好，可以在存储库层通过构建更好的查询来解决这一问题，而不必担心其他部分。如果逻辑中有一个bug，您可以在不依赖数据库的情况下修复它，只需构建一个单元测试用例并更新服务层，然后就可以使用它了

对于一个只有简单用例的单人秀来说，分层很烦人。这是一个应用程序的必要条件，该应用程序应该能够与许多不同的客户和多人一起长期使用

---

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

正如您的第一句话所示，这个问题是基于意见的。因此，这是离题的。我同意，但即使是基于意见的问题也能得到最好的答案。我不认为这有什么离题的地方，你仍然可以给出一个相当主观的答案来指导我和其他可能有相同问题的人。@Eksapsy如果主要是基于观点的，那就离题了。也就是说，没有办法给出权威性的答案。这不是关于给出你的意见，而是关于给出指导。如果你不想发表意见，你不必发表意见。当有人问你要买什么游戏机时，你不必告诉他

---

我是PS4。你可以问他需要什么，这样他就可以得出自己的结论，而不需要你给出自己的意见。好吧，服务层存在的原因不是提供数据库可以做的事情，既不包括业务逻辑，因为正如我所演示的，数据库在这方面更好、更高效，但提供诸如缓存、调用单独的微服务等逻辑。我做对了吗？只是为了确保我100%的理解正确。您的答案非常理想，信息量非常大，而且对任务来说是主观的，而不是主观的。一些业务逻辑在数据库附近/内部执行得非常好，而其他业务逻辑则不然。特别是当数据来自多个来源时——其他微服务、来自其他组织的各种API、缓存等。。。假设您希望从许多金融交易创建税务报告。我会从回购协议中查询相关交易，并在服务层进行计算。