标题说明了一切。
假设我有一个单独的类，它在某些 DSL 中用作查询处理器。也就是说，我用一些 DSL 向它提供一些查询，然后它运行这个查询。
该查询处理器将与我使用的任何数据库连接器库进行对话，并仅提取与条件匹配的记录的ID 。
这......假设“集合”，ID 将被提供给类，该类将对数据库执行实际的 ORM 并从具有此 ID 的记录构造域对象。
这样，我就不需要在我的 ORM 机制中包含查询解析能力，它只会有一个完全愚蠢的方法来通过它们的 ID 获取记录。
另外，假设我可以想象到所有类型的缓存，从网页缓存到 DBMS 查询缓存。
与传统的（SQL 或者可能是 MongoDB 风格的）查询构建并直接在数据库上运行它们相比，这个方案的性能真的很差吗？
我已经明白，所有这些都将需要每个 fetch 操作两个查询，而不是一个。我的问题是关于差异的大小。
我的总体目标是将执行查询的接口与此查询获得的实际对象的接口分开。例如，YiiCActiveRecord就失败了，它是三个不同职责合并在一起的组合。