Comments 6
Хорошая статья
Попробую данный подход на своем pet-проекте
Использовал RawQuery в своем проекте, он помог избежать создания 4 лишних таблиц с 16 дублями одних и тех же методов. Ваш же подход лишен какого-либо практического смысла. Зачем еще одна абстракция над Room? Эта библиотека сама является оберткой над SQLite и скрывает особенности работы с БД, а вы заново прокидываете их наверх.
Да, код можно уменьшить, но главная задача кода - быть понятным для разработчика, чтобы тот быстро сделал функционал или изменил текущий. В вашем же решении появляется куча оберток, в которых сначала потребуется разобраться, потом написать тесты по TDD для Room, потом написать код под DI, и только потом добавить интерфейс с Update/Insert. Как по мне, скопировать две строчки будет намного быстрее и продуктивнее.
Вы правы, когда приложение использует до 5 таблиц, где часть запросов уникальна, использовать данный подход будет неуместной потерей простоты на ненужные абстракции.
С другой стороны, когда у вас 20 таблиц, в каждой используется по 10 одинаковых запросов к бд, у вас каждый DAO будет наполнен значительным количеством методов и при добавлении нового функционала который, затрагивает 6 таблиц, вам нужно будет копипастить одно и то же в каждую таблицу, а потом еще для каждой из этих таблиц запускать тесты на каждую реализацию этого метода.
Конечно можно не писать тесты, но тогда зафакапиться можно как с Query, так и с RawQuery.
Сила @RawQuery. Сокращаем код DAO на 90%