Comments 12
Хмм... Любой уважающий себя Java-разработчик обязан написать как минимум 1 ORM/JDBC-коннектор, 1 контейнер/DI/AOP, 1 кодогенератор/интерпретатор/компилятор. А лучше 5. Это единственный нормальный путь становления сеньором — и других наверное, нет.
Если вам удалось в одном проекте покрыть сразу несколько перечисленных категорий, значит, вы всё делаете правильно, и станете хорошим Java-сеньором. А если у вас хватает наглости выложить его в паблик, и добавить в название true/ultimate, то вы имеете все шансы стать просто отличным Java-сеньором. Большинство почему-то стесняется :)
Но хватит похвалы. Подобного DO layers написано очень много — я лично штук 6 имплементаций видел, заточенных под конкретный проект, и сам как минимум три писал (ещё более специализированных). У всех один недостаток: если надо сделать шаг влево или вправо от видения автора, то сразу приплыли. Сколько ни думай головой, заранее всех кейсов не продумаешь.
Но за выкладку в паблик зачёт, конечно.
Не очень понимаю восторги. У нас в 2 проектах точно такие же штуки написаны. В одном попроще, в другом чуть посложнее. Аннотаций, кстати, нет ни там ни там. Где попроще - там самая увесистая часть это маппер из кортежей в объекты на 370 строк.
У нас запросы к БД простецкие, для них такой колхоз пойдет. Как общее решение для вообще любого проекта - да ну, вы шутите. При живом-то JOOQ.
Для большей трушности можно еще добавить github workflow для релиза, и для солидности добавить тесты на других версиях джава https://github.com/pain64/true-sql/blob/main/.github/workflows/gradle.yml#L28.
Спасибо за предложение, и за то что ознакомились с проектом. Пока пароли от maven central храним на отдельной машине. По поводу версий Java, то основная версия это 21+. Во многом, потому что было самим очень удобно реализовать TrueSql на свежей джаве. Бэкпорты на 17 и ниже стоят в планах, но тут ждем запроса от вендоров
Я просто оставлю это здесь: https://jdbi.org/
Как описывается маппинг от таблицы/запроса к полям dto (бизнес-объекта)? С условием, что dto нельзя засирать аннотациями? Имеется отдельный слой persistence, в методы которого входят/выходят dto.
Приветствую!
record User(long id, String name) {}
ds.q("select id, name from users").fetchList(User.class)
Шаг 1. TrueSql, в классе dto (User) ожидает конструктор с ненулевым количество параметров. Если его нет, или их несколько - ошибка компиляции
Шаг 2. Генерирует маппер вида new User(rs.getLong(1), rs.getString(2))
Шаг 3. Если включена проверка запросов, то проверяется соответствие выходных колонок запроса сигнатуре конструктора (количество параметров, типы)
А в режиме генерации dto:
ds.q("select id, name from users").g.fetchList(User.class)
TrueSql сам создаст класс User. Имена полей получит путем преобразования имен выходных колонок из snake_case в camelCase
Верю, вы продумали какие функции должны быть у библиотеки такого класса и как сделать ее компактной и быстрой.
Но забыли продумать, как сделать, чтобы разработчику было удобно. Синтаксис и стиль кода противоестественные, местами ставящие в тупик. Раскрыл бы мысль, но еще ни разу не сталкивался, чтобы такую критику воспринимали конструктивно. Да и формировать реестр видимых недостатков эргономики, это времени требует.
TrueSql — ультимативный sql-коннектор для Java