Laravel 资源还是定制存储库？

积累知识，胜过积蓄金银！毕竟在文章开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《Laravel 资源还是定制存储库？》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

本周早些时候，在使用 laravel rest api 时，我遇到了超时错误的烦恼。它导致最终用户对开发问题感到沮丧。让我简单介绍一下整个场景：

我需要从外部数据源加载数据，过滤它，然后准备 json 返回。数据量不大，单次请求只有10k左右。当我在检索和过滤它们后尝试格式化它们时，出现了主要问题。所以，我开始使用以下步骤进行调试：

• 检查查询是否已优化以及列是否已建立索引。

• 确保使用 chunk 方法

• 检查格式化仓库没有使用任何不必要的方法/参考/实现/未使用的函数/外部api调用。

所有检查均已完成，但仍然显示网关超时错误，因为它超过了 1 分钟。服务类如下所示：

repo 类如下所示：

肉眼看来，10k+数据处理和操作不应该抛出超时错误。我们将在最后讨论为什么会发生这种情况（可能不是实际的具体原因，但有可能），现在讨论如何使用 laravel api 资源解决它。

实施起来很简单。首先，从命令行生成 laravel api 资源：

php artisan make:resource DataFormatterResource

然后，将您的模型对象发送到资源并按照下面给出的要求格式化/操作您的数据：

令人惊讶的是，只用了3.7秒就回复了?！
我试图在这里挖掘出真正的问题，并发现了一些可能的情况，上面提到了最后的定义。给出案例：

1. laravel api 资源提供了一个一致的接口来访问和操作数据，我在其中使用带有一些依赖注入的存储库。这使得更容易编写高效的代码并避免常见的性能瓶颈。
2. laravel api 资源针对性能进行了优化，因为它们使用缓存和其他技术来提高数据检索和处理的速度，而我只选择数组原始格式的块。
3. laravel api 资源根据请求标头自动将数据库查询结果序列化为 json 或 xml。这为您省去了编写自己的序列化代码的麻烦。

在我的项目的大多数服务中，我在服务层使用了存储库或功能格式化程序，但在这种情况下，我遇到了一个困难，可能有其他原因导致此问题发生。
我想强调的是，在使用模型时，laravel resources 在一些棘手的情况下可能会派上用场。

如果您喜欢这篇文章，请留下鼓掌或评论。

本篇关于《Laravel 资源还是定制存储库？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！