php - 如何使用存储库模式来处理复杂的读取(SELECT)？

Question

我见过很多 $repo->findAll() 或 $repo->findById($id) 示例，但我正在寻找如何对此进行扩展以进行更复杂的读取。

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

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

我不确定我是否适合使用现有的查询生成器包，因为我不确定它的可测试性和数据库无关性(换句话说，它可能是>太灵活)。我确实知道我不想在这个项目中使用 ORM。我改用数据映射器+存储库方法。

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

Answer 1

(有时，我相信问题的“答案”涉及“降低期望”。)

我相信您对“存储库模式”的要求太多了。有许多第三方软件包试图将用户与 MySQL 隔离。它们通常都有局限性。通常，限制在于扩展——它们的设计目的不是以复杂的方式处理庞大的数据集。

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

让我来分析一下您的两个“要求”。它们适合封装，但不一定适合存储库模式。

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

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

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

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