StorIO — человеческий API для работы с SQLiteDatabase и ContentResolver

    Не секрет, что API SQLiteDatabase и ContentResolver — отстой, поэтому многие стараются от них абстрагироваться. Кто-то выбирает ORM, кто-то DAO, кто-то пишет своё.

    За долгие годы Android разработки мы прошли через все эти этапы: ORM часто становится узким местом в критический для проекта момент, своё DAO требует тестирования и разработки, что отнимает много времени, которое можно было тратить на другие детали реализации приложения, готовые DAO в принципе решают вопрос, но различные библиотеки имеют свои плюсы и минусы (15стандартов.jpg), посмотрите, что предлагаем мы:

    1. API для людей: удобные билдеры (помните 5-7 nullов в запросах?), читаемые и очевидные конструкции, Immutability и Thread-safety.
    2. Упрощенный набор операций: вместо стандартного CRUD (Create-Read-Update-Delete или Insert-Select-Update-Delete) мы предлагаем три операции — Put, Get, Delete, при этом вы имеете полный контроль над их реализацией, можете, например, упороться и хранить один объект в нескольких таблицах и так далее.
    3. Опциональный Type-Safe Object Mapping без Reflection, но если вы хотите работать с Cursor или ContentValues — пожалуйста.
    4. Некая схожесть с Retrofit: вы можете выполнить любую операцию как блокирующий вызов либо как rx.Observable, мы можем добавить callback модель выполнения операций в будущем.
    5. Reactive — Observable из Get операции будет получать уведомления об изменении таблиц в случае SQLite или Uri в случае ContentResolver, это позволяет полностью заменить лоадеры, API которых просто отвратителен.


    Причины попробовать StorIO:
    • Open Source -> меньше багов
    • Документация, Sample приложение, дизайн тесты -> меньше багов
    • Unit и Integration тесты -> меньше багов
    • Простой концепт трёх основных операций: Put, Get, Delete -> меньше багов
    • Практически всё immutable и thread-safe -> меньше багов

    Почему мы сделали StorIO:

    Мы устали от необходимости передавать убогие 5-7 параметров для запросов, половина из которых null, а другая — массив с одним элементом и вызовом String.valueOf() -> поэтому в StorIO у запросов есть удобные билдеры, а сами запросы immutable и их можно сохранять и использовать обобщенно.

    Мы устали от Object-Mapping с кучей ограничений в разных библиотеках -> поэтому в StorIO нет никаких ограничений на Object-Mapping, не хватает дефолтного — вы вправе реализовать свое поведение каждой операции для конкретного типа данных.

    Мы устали от того, что нужно понять, что надо сделать: insert или update перед каждым вставкой/изменением данных -> поэтому в StorIO это объединено в операцию Put.

    Мы устали от того, что ORM всегда будет ORM и он либо будет генерить тупейшие запросы с ненужной сложностью в некоторых случаях, либо вы
    просто наткнётесь на какое-то ограничение, которое этот ORM не даст вам решить -> поэтому StorIO не ORM, а по-сути DAO.

    Мы устали от того, что никто толком не может сделать нормальную поддержку Rx, да есть SqlBrite, но давайте разберемся — он low-level, в нем нет Object Mapping из коробки, BriteContentResolver содержит только один метод query, BriteDatabase по сути предоставляет те же самые методы, что и SQLiteDatabase со всеми их минусами, но да, ребята из Square в общем то единственные, кто реализовал Rx автоапдейт результатов запросов. В StorIO мы пошли дальше и запили всё, о чём написано выше + нормальный Rx, StorIO это наш «merge» хороших концепций, API, подходов разных библиотек (даже Retrofit, внезапно) и нашего опыта, такие дела.

    Репозиторий StorIO: github.com/pushtorefresh/storio

    Фидбек очень приветствуется.
    • +12
    • 12,3k
    • 9
    Поделиться публикацией

    Комментарии 9

      0
      Сделайте видео-урок по использованию этого проекта.
        +1
        Судя по документации, описанной на github её вполне достаточно для того, чтобы начать пользоваться данным проектом.
          0
          Никогда не понимал видео-уроков, где в IDE пишут код. Если видео-уроки, то примерно такие www.youtube.com/watch?v=32i7ot0y78U
            0
            Это сарказм такой, из всех инженеров гугла привести в пример Яна, коромыслом пришибленного?) Сколько минут из всех двух вы выдержите на этом видео? https://www.youtube.com/watch?v=THadGrPeSJM
            +1
            Думаю нет, не будем делать видеоуроков, есть документация, Sample App, дизайн тесты. Потом вы попросите видеоурок на русском, их надо будет обновлять с новыми версиями т.д. и т.п., не видел видеоуроков ни по одной библиотеке из тех, что мы используем и никогда не хотелось.

            Ничего личного :)
            0
            RxJava радует. Будем смотреть, пробовать.
              0
              Рады радовать :) А мы будем рады вашему фидбеку тут или, например, мне на почту: artem.zinnatullin@gmail.com.
              0
              Предположим есть объект, у которого одно из полей класса — List других элементов.
              Как должно происходить сохранение объекта в базу, как должен работать маппинг и т.д.
              В документации и в sample app я не нашел подобного примера.
                0
                Я вижу два стула кейса:

                1. Вложенный List других элементов, которые можно просто положить в ContentValues в каком то виде, скажем в виде строки из сериализованного JSON, если это, скажем, массив чисел — числа через запятую, соответсвенно, в Get резолвере нужно их парсить обратно в List объектов.
                2. Вложенный List других элементов, которые являются другими сущностями в базе данных, тут можно написать такие Put/Get/Delete резолверы, что они будут соответсвенно класть эти элементы в другие таблицы/доставать их из других таблиц/удалять из других таблиц.

                Я сторонник варианта 1 и избегания варианта 2, но StorIO не ограничивает вас ни в первом варианте, ни во втором, более того, этот вопрос не особо входит в рамки работы StorIO, т.к. это больше удобный враппер над SQLiteDatabase/ContentResolver, чем DAO и тем более не ORM.

                Если остались вопросы — спрашивайте!

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое