阻抗不匹配：存储库模式 + 映射器 + 光标 + SQLite答案

【问题标题】：Impedance Mismatch: Repository pattern + Mapper + Cursor + SQLite阻抗不匹配：存储库模式 + 映射器 + 光标 + SQLite
【发布时间】：2013-10-11 17:51:25
【问题描述】：

我正在构建基于存储库模式的 ORM。在存储库中，我创建了一些我称之为“数据源”的东西来从数据库中获取结果并将它们映射到实体对象。每个数据源都是使用查询创建的，负责获取第一行的单个结果或所有结果。虽然数据源主要负责从（准备好的）查询中获取单个或所有对象，但它也可以作为在创建数据源期间设置的“游标”的代理。我将光标放在引号中，因为它实际上是一个主键数组，稍后用于使用这些 ID 从存储库中获取实体。这种类似游标的实现是由于 SQLite 在这种情况下在游标方面没有提供更好的东西。

所以数据源提供了singleEntity()、allEntities()、firstEntity()、nextEntity()、previousEntity()、entityAtIndex()。如前所述，除前两个之外的所有内容实际上都在使用光标。游标是从与数据源相同的查询创建的（但自动优化以限制游标的选定字段）。

存储库本身提供 CRUD 功能（getById()、remove()、create()、update()）。

这一切都很好，大部分只是常见的模式实现......但刚才我意识到以下问题：

即使存储库本身应该用于按 ID 获取实体，存储库中的数据源可能只是对数据使用不同的投影 - 或仅使用可用数据的子集。因此，它可能会返回与默认存储库 getEntityById() 将返回的内容不同的或只是一些替代映射。

应该如何改变设计？ 1) 不允许默认 repo getter 以外的其他映射？ => 可能是糟糕的设计。如何控制对数据源的查询等。 2) 强制用户为光标设置自定义查询以创建索引+ fetcher 查询以按 id 获取单个结果？ => 比以前的想法更好，但也意味着可能出现不一致的地方，以防游标提取器的设置与数据源结果映射不同。 3）希望我还没有想到的东西。我仍然可以轻松地重新设计完整的 API

【问题讨论】：

标签： sqlite orm repository-pattern datamapper

【解决方案1】：

为了回答我自己的问题，我得出的结论是，处理它的唯一有效方法是要求用户使用 fetch-query 创建 SQL 游标，按照惯例，它必须能够使用数据源用于从数据库中获取记录的相同投影。游标索引（带有键对的数组，rowid）缓存是通过重用数据源的相同查询来创建的。为方便起见，实体数组是从原始数据源查询创建的，当用户使用其中一种游标方法而没有创建优化的 SQL 游标时，将创建该数组。

这样，它总是在默认模式下具有正确的映射（如前所述，当没有创建特殊游标时使用数据源中的实体数组），以及用户负责创建它的 sql 游标模式下的映射.

假设任何不同是没有意义的，因为 SQLite 中没有真正的光标。

【讨论】：