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



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

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

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

这可能很好,其中大部分只是常见的模式实现......但是现在我意识到以下问题:

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

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

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

这样,它将始终在默认模式下具有正确的映射(如前所述,在没有创建特殊游标时使用数据源中的实体数组(,以及 sql 游标模式下的映射,这是用户负责创建它的映射。

假设任何不同的东西是没有意义的,因为SQLite中没有真正的游标。

最新更新