Сопротивление импеданса: шаблон хранилища + сопоставление + курсор + SQLite

Question

Я строю ORM на основе шаблона репозитория. Внутри репозитория я создаю что-то, что я называю «источником данных», чтобы извлекать результаты из db и сопоставлять их объектам сущности. Каждый источник данных создается с запросом и отвечает за получение либо одного результата для первой строки, либо всех результатов. Хотя источник данных в основном отвечает за получение одного или всех объектов из (подготовленного) запроса, он также работает как прокси-сервер для «курсора», который устанавливается во время создания источника данных. Я помещаю курсор в кавычки, потому что на самом деле это массив первичных ключей, которые позже используются для извлечения сущностей из репозитория с использованием этих идентификаторов. Эта подобная курсору реализация связана с SQLite, которая в этом случае не предлагает ничего лучшего в отношении курсоров.

Таким образом, источник данных обеспечивает singleEntity(), allEntities(), firstEntity(), nextEntity(), previousEntity(), entityAtIndex(). Как говорилось ранее, все, кроме первых двух, фактически используют курсор. Курсор создается из того же запроса, что и источник данных (но автоматически оптимизирован для ограничения выбранных полей для курсора).

Репозиторий сам по себе предоставляет функции CRUD (getById(), remove(), create(), update()).

Это может быть все хорошо, большинство это только общая реализация шаблона ... Но только теперь я понимаю, следующая проблема:

Несмотря на то, что это само хранилище, которое должно быть использовано для извлечения объекты по идентификатору, источник данных в репозитории может просто использовать другой прогноз для данных - или только подмножество доступных. Таким образом, он может возвращать другое или просто некоторое альтернативное сопоставление тому, что будет возвращать репозиторий по умолчанию getEntityById().

Как следует изменить дизайн? 1) Запретить другие сопоставления, нежели репозиторий-репозиторий по умолчанию? => Было бы плохой дизайн, наверное. Как управлять запросами для источников данных и т. Д. 2) Заставить пользователя настраивать пользовательские запросы для курсора для создания запроса индекса + выборщика для получения отдельных результатов по идентификатору? => Лучше, чем предыдущая идея, но также будет означать вероятное место для несогласованности в случае, если установщик курсора отличается от сопоставления результатов источника данных. 3) Надеюсь, что-то, о чем я еще не думал. Я все еще могу легко перепроектировать полный API

Answer 1

Чтобы ответить на мой собственный вопрос, я пришел к выводу, что единственный правильный способ его обработки - потребовать от пользователя создания курсора SQL с помощью запроса-выборки, который по соглашению должен иметь возможность извлекать один объект, используя тот же самый прогноз, который использует источник данных для извлечения записей из db. Индекс курсора (массив с парой ключей, rowid) создается путем повторного использования одного и того же запроса источника данных. Для удобства массив объектов создается из исходного запроса источника данных, который будет создан, когда пользователь использует один из методов курсора без создания оптимизированного курсора SQL.

Таким образом, он всегда будет иметь правильное отображение в режиме по умолчанию (с использованием массива entites из источника данных, когда не было создано специального курсора, как упоминалось ранее), и отображение в режиме курсора sql, который является обязанностью пользователя создавать Это.

Просто не имеет смысла предполагать что-либо другое, поскольку в SQLite нет реального курсора.