我已经看过很多$repo->findAll()或$repo->findById($id)示例，但我正在寻找如何针对更复杂的Read进行扩展。
例如，假设我有一个表示SELECT查询的数据网格，其中包含多个JOIN。我需要做这些事情：
WHERE条件，其中一些条件发生在查询的JOIN条款中）SELECT *，所以我需要指定我想要的字段）我不确定我是否习惯使用现有的查询构建器包，因为我不确定它是多么可测试且与数据库无关（换句话说，它可能是 >太灵活）。我知道我不想在这个项目中使用 ORM 。我正在使用 Data Mapper + Repository 方法。
如何使用存储库模式执行此操作？
答案 0 :(得分：0)
（有时，我相信＆＃34;答案＆＃34;问题涉及＆＃34;降低期望＆＃34;。）
我相信你对于一个＆＃34; Repository Pattern＆＃34;要求太多了。有许多第三方软件包试图将用户与MySQL隔离开来。它们通常有局限性。缩放通常是一种限制 - 它们并非旨在以复杂的方式处理大型数据集。
每当我使用Repository Pattern时，似乎我只是在封装一个（或几个）SQL语句并将封装的方法（子例程）放在一个单独的文件中。哦，我相信这样做。我只是不相信魔法。
让我挑选你的两个要求＆＃39;。它们适用于封装，但不一定适用于存储库模式。
使用OFFSET和LIMIT的分页...对于简单的数据集，这很好用。但我看到一个项目在他们这样做之后融化了。他们需要明显的参数（偏移和限制）并做了显而易见的事情（构造和执行SELECT ... OFFSET $offs LIMIT $lim）。然后他们建立了一个拥有126,000页＃34页的网页。值得的数据。然后做了Next，Next，Next，......直到系统熔化。
问题取决于偏移和限制，而不是＆＃34;下一步＆＃34;和＆＃34; Prev＆＃34;和＆＃34;记住你离开的地方＆＃34;。 （我有一个关于该主题的博客。）请注意＆＃34;解决方案＆＃34;无法在封装的例程中执行，但涉及UI更改和用户期望更改，以及代码。
我要评论的另一个是SQL_COUNT_FOUND_ROWS ...这么简单，那么容易。但是这么致命。就像本周最近一样，我建议某人的数据增长如此之多，以至于他因计数技术而出现性能问题。许多可能的解决方案涉及的不仅仅是卡在存储库模式中。例如，典型的搜索引擎很久以前就在获取确切的计数时受到了抨击，而是“＃34;”管理用户期望＆＃34;通过显示＆＃34; 中的10个项目 1,340,000＆＃34;。毫无疑问，它在很多地方占用了大量代码，而不仅仅是对一个SQL语句的简单增强。它可能需要多台服务器。
所以，封装 - 是的。存储库模式 - 仅在某种程度上。并成为原始SQL的专家。