如何使用存储库模式来处理复杂的读取（选择）？答案

【问题标题】：How to use the Repository Pattern to handle complex Reads(SELECTs)?如何使用存储库模式来处理复杂的读取（选择）？
【发布时间】：2015-03-05 22:38:34
【问题描述】：

我已经看过很多 $repo->findAll() 或 $repo->findById($id)examples，但我正在寻找如何在此基础上进行扩展以实现更复杂的读取。

例如，假设我有一个数据网格，它表示一个 SELECT 查询，其中包含多个 JOIN。我需要做这些事情：

排序
过滤（WHERE 条件，其中一些发生在查询的JOIN 子句上）
列（我不想SELECT *，所以我需要指定我想要的字段）
限制（分页）
计数（我需要知道所有页面的总行数。也许我在单独的 repo 方法/查询中执行此操作。）

我不确定我是否愿意使用现有的 查询构建器 包，因为我不确定它的可测试性和与数据库无关（换句话说，它可能是 太灵活了）。我知道我不想在这个项目中使用 ORM。我正在使用 Data Mapper + Repository 方法。

我将如何使用存储库模式来做到这一点？

【问题讨论】：

标签： php mysql repository-pattern laravel-5

【解决方案1】：

（有时，我认为问题的“答案”涉及“降低期望”。）

我相信您对“存储库模式”的要求太高了。有许多第 3 方软件包试图将用户与 MySQL 隔离开来。它们通常有局限性。通常在扩展方面存在限制——它们并非旨在以复杂的方式处理庞大的数据集。

每当我使用存储库模式时，似乎我所做的只是封装一条（或几条）SQL 语句并将封装的方法（子例程）放在单独的文件中。哦，我相信这样做。我只是不相信魔法。

让我挑出你的两个“要求”。它们有利于封装，但不一定适用于存储库模式。

使用 OFFSET 和 LIMIT 进行分页...对于简单的数据集，这很好用。但是我看到一个项目在他们这样做之后就崩溃了。他们需要明显的参数（偏移量和限制）并做了明显的事情（构造和执行SELECT ... OFFSET $offs LIMIT $lim）。然后他们建立了一个包含 126,000“页”数据的网页。然后下一步，下一步，下一步，……直到系统崩溃。

问题在于偏移量和限制，而不是“下一个”和“上一个”，以及“记住你离开的地方”。（我有一篇关于该主题的博客。）注意，“解决方案”不能在封装的例程中执行，而是涉及 UI 更改和用户期望更改，以及代码。

我要评论的另一个是 SQL_COUNT_FOUND_ROWS... 如此简单，如此容易。但是太致命了。就在这周，我建议某人的数据增长如此之多，以至于由于这种计数技术而导致他遇到性能问题。许多可能的解决方案涉及的不仅仅是存储库模式。例如，典型的搜索引擎很久以前就强调获得确切的计数，而是通过显示“大约 1,340,000 中的 10 项”来“管理用户期望”。毫无疑问，这在很多地方使用了大量代码，而不仅仅是对一条 SQL 语句的简单增强。可能需要多台服务器。

所以，封装 - 是的。存储库模式 - 只是有点。并成为原始 SQL 方面的专家。

【讨论】：

是的，Rick，我认为你的想法是正确的。我只需要封装（这可能会减少我的查询总数）并将这些查询全部保存在一个地方（在几个文件夹中，但都在一个父文件夹下......而不是分散在整个应用程序中）。目标也是确保查询将数组/对象返回到应用程序的其余部分，以便应用程序的其余部分保持与数据库无关，并且我可以轻松测试（模拟从查询返回的数据）。
另外，感谢您对分页和 COUNT 的提醒。我过去读过这些警告。我会看看我是否可以更新 jqGrid 以仅使用“prev”“next”和“last”链接。到目前为止，让我们保持活力的事情是密切关注 RAM 的需求（只要“热”数据留在 RAM 中，我们就很好），而且我已经将我的主键设置为复合键以我们主要过滤数据的方式（换句话说，这些主键帮助我们的查询将数据拼接成适当大小的块，因此分页/计数/等不会成为问题）。
仅供参考，我不太信任 ORM 的事实应该告诉您，我对原始查询非常满意。 :-)
哦，还有一件事，你说得对，我不能指望回购模式在这里成为灵丹妙药。我只需要尽我所能来封装它，将它们放在一个中心位置，并使其易于其他开发人员理解和使用。这些数据库还没有设计为以类似“对象”的方式执行（或至少执行良好）。
盲目地将一行作为一个单元来处理可以让 ORM 和任何基于它的 toy 应用程序的工作变得轻松。但它不适用于严肃的应用程序。