Comments 14
Иду к вам в ЛС
Неплохо было бы поглядеть хотя бы базовый пример. Т.е. вот схема БД, вот запросы, а вот сгенерированный SDK.
p.s.на сайте информации тоже нет, предлагается записаться на демо
Спасибо за конструктивный фидбек! Скоро дополним.
Опубликовал следующий пост в виде туториал с примером: https://habr.com/ru/articles/781550/
Мы разработали собственный инструмент. Заходите на ..., чтобы узнать больше.
И ни одного нормального примера в статье. Спасибо, ловите минус. Такой уровень статей Хабре мне (и, надеюсь, остальным) не нужен.
Спасибо. Примеры выложил в новой статье в виде туториала: https://habr.com/ru/articles/781550/
Два момента:
Я подписан на хаб Rust и прилетела эта статья. Причем тут Rust, я не понял.
Есть еще один подход, который не упомянули авторы статьи. В библиотеке SLICK (Scala) этот подход назвали Functional Relational Mapping. Библиотека Exposed - реализация этого подхода для Kotlin - позволяет написать любой запрос к БД оставаясь в рамках типизированной модели.
Спасибо! Я бы обе библиотеки отнёс к ORM. Они так же подходят к проблеме с помощью абстракций и относятся к SQL как к байткоду и прячут его.
Это не совсем корректно, т.к. задачи они все-таки решают разные. ORM как инструмент должен сделать маппинг между миром ООП и миром реляций в СУБД. А exposed/slick как и myBatis все-таки мапит не таблицы. а результаты запросов. Я с jooq не работал, но подозреваю что по стилю использования exposed ближе к нему, чем к Hibernate.
Стандартный язык SQL =) Ну допустим.
Но кодогенерация декораторов для датасетов, да еще и сильно завязанная на конкретную СУБД ...
Какие-то лихие 80е
Тоже добавлю несколько слов в тему:
Глубокая зависимость архитектуры приложений от дизайна базы данных - ограничение не новое - Мартин пишет очень доходчиво и подробно уже много лет. Всем рекомендую.
Наличие инструментов, способных "гнуть" структуру базы данных на уровне модели ORM годно исключительно для макетирования и ранних этапов прототипирования. Их не безопасно (речь о целостности) использовать на более поздних этапах развития (даже если оставить ORM в режиме строгой валидации схем).
Решение задачи повышения уровня абстракции можно выполнить только над моделью данных, а значит - почти во всех сервисах, которые так или иначе на неё будут опираться, её придётся раскрывать в достаточной мере: риски фрагментации архитектуры и снова безопасность, но теперь уже с ракурса доступности и конфиденциальности.
Таким образом, вопросы есть. Причём именно из позиции разработки архитектуры, обеспечивающей гибкость расширения и контролируемую стоимость владения. Аспекты: "модно-молодёжно" и "увлекательное приключение" - сейчас не берём.
О eDSL:
Не все готовы: "молодёжь", распробовшая на вкус итераторы (например, параметрические - а здесь можно ваять так, что деловые правила вообще не будут проникать в императивную логику), ещё не скоро устанет от их написания - им объективно потребуется время (я сейчас без снисхождения или иронии). Это важный опыт, который даст путь от них отказаться в будущем.
Но если готовность есть, не всё так однозначно. Этот подход действительно может не только сглаживать углы, так как секрет успеха здесь - удачный дизайн доменной модели в контексте её поведения.
Поэтому, Коллеги, появление новых подходов в этой теме:
Во-первых, повод для конструктивной дискуссии: ибо, полагаю, "задолбало" всех. Особенно, Redis ;-).
Во-вторых, повод для анализа: так как новые пути могут открываться в процессе обсуждения, пусть и ожесточённого.
В связи с этим, нахожу подход в подчинённом задачам архитектуры (!) автоматическом (?) создании контекстной модели управления данными, который предлагает Никита, представляющей интерес историей.
Вместе с тем, статья, увы не раскрывает сути подхода на достаточную глубину, но зато говорит о "разливающейся в этом месте магии". Никита, мне не хватило деталей. Готов помочь с описанием, если найдёшь это уместным.
Автоматизация разработки с помощью подхода DB-first