Да, возможно dto я зря употребил, читай как entity. Но в ef core entity можно описывать без атрибутов/аннотаций, вся конфигурация будет в DbContext. Про java не скажу, но не понятно, почему не рассматриваете jooq https://www.jooq.org/doc/latest/manual/sql-execution/fetching/pojos/.
Для нас размещение такой информации в базе и генерация по ней кода неприемлемо, потому что необходимо менять слой persistence от базы к базе и даже к nosql, при этом требуется, чтобы слои бизнеса не менялись.
Если у вас entity и dto сильно отличаются, то здесь без написания кода не обойтись.
Концепция хорошая, но не новая :) В ef core есть scaffold, который по существующей базе сгенерирует dto и контекст бд, в linq2db есть шаблоны для генерации dto. Для проекций dto в linq изначально имеет анонимный тип, который при необходимости с помощью рефакторинга превращается в именованный тип. Не удивлюсь, если для hibernate и jooq можно также всё настроить.
Мне кажется, но в мире dotnet этих проблем уже нет. Хочешь быть поближе к базе, то есть dapper и linq2db. Хочешь удобств и функциональности, то есть ef core:
свой язык декларации схемы данных
Миграции ef core: один язык для разных СУБД. В идеале модели не меняются, для другой СУБД надо только сконфигурировать новый контекст.
свой язык запросов (Criteria Api, HQL, JPQL)
LINQ -- это лучше, чем учить t-sql, pl/sql и pgplsql. Но если очень хочется, то есть возможность выполнить raw sql.
свой оптимизатор (anti N+1)
Здесь от провайдера зависит, в текущих реализациях не сталкивался с такой проблемой.
свой pl/SQL - API вокруг Entity Manager, Sessions со скриптингом на Java
DbContext, DbSet, IQueryable, Expression -- вполне понятные стабильные api.
connection.fetch(query, args) -> result
Идея хорошая, но есть ряд проблем:
нужна поддержка на уровне языка, у шарпа есть source generators, а в мире java что?
где брать метаданные для вывода типов? что делать если sql динамический или СУБД не умеет отдавать эти данные?
Начнешь эти проблемы решать и сделаешь еще один орм, только с сырым sql :)
Как-то странно видеть такие претензии, когда альтернатива динамическая типизация :) Любая IDE показывает тип без копания в коде и при необходимости поможет зарефакторить на конкретный тип парой нажатий.
В моем чайнике lua нет :) Отсутствие типизации в текущих реалиях сложно чем-то объяснить. Язык с типизацией всегда проще использовать, чем язык без нее.
А tauri? Я в части dotnet его не смотрел, только react пробовал собирать, но он предлагает написать приложение на blazor.
Таких проектов сейчас достаточно много. Тот же tauri предлагает сделать из blazor десктоп приложение. Если поискать, то можно найти еще https://github.com/tryphotino/photino.NET, https://github.com/ElectronNET/Electron.NET, https://github.com/JBildstein/SpiderEye.
Да, возможно dto я зря употребил, читай как entity. Но в ef core entity можно описывать без атрибутов/аннотаций, вся конфигурация будет в DbContext. Про java не скажу, но не понятно, почему не рассматриваете jooq https://www.jooq.org/doc/latest/manual/sql-execution/fetching/pojos/.
Если у вас entity и dto сильно отличаются, то здесь без написания кода не обойтись.
Было:
Стало после рефакторинга "To named type" в Rider:
И да, dbContext и тип Sign получены командой `dotnet ef dbcontext scaffold` из существующей БД.
Концепция хорошая, но не новая :) В ef core есть scaffold, который по существующей базе сгенерирует dto и контекст бд, в linq2db есть шаблоны для генерации dto. Для проекций dto в linq изначально имеет анонимный тип, который при необходимости с помощью рефакторинга превращается в именованный тип. Не удивлюсь, если для hibernate и jooq можно также всё настроить.
Мне кажется, но в мире dotnet этих проблем уже нет. Хочешь быть поближе к базе, то есть dapper и linq2db. Хочешь удобств и функциональности, то есть ef core:
Миграции ef core: один язык для разных СУБД. В идеале модели не меняются, для другой СУБД надо только сконфигурировать новый контекст.
LINQ -- это лучше, чем учить t-sql, pl/sql и pgplsql. Но если очень хочется, то есть возможность выполнить raw sql.
Здесь от провайдера зависит, в текущих реализациях не сталкивался с такой проблемой.
DbContext, DbSet, IQueryable, Expression -- вполне понятные стабильные api.
Идея хорошая, но есть ряд проблем:
нужна поддержка на уровне языка, у шарпа есть source generators, а в мире java что?
где брать метаданные для вывода типов? что делать если sql динамический или СУБД не умеет отдавать эти данные?
Начнешь эти проблемы решать и сделаешь еще один орм, только с сырым sql :)
Как-то странно видеть такие претензии, когда альтернатива динамическая типизация :) Любая IDE показывает тип без копания в коде и при необходимости поможет зарефакторить на конкретный тип парой нажатий.
Вывод типов же. С ним указывать типы надо будет большей частью только в сигнатурах методов.
PL/SQL язык из 80-х, синтаксически основан на языках из 60-х. Молодым его тоже не назавешь :)
В моем чайнике lua нет :) Отсутствие типизации в текущих реалиях сложно чем-то объяснить. Язык с типизацией всегда проще использовать, чем язык без нее.
Золотая серидина между консольными командами и эксплорероподобными программами. Если не секрет, то расскажи, чем пользоваться удобнее.
Перл, питон, пхп -- они же близнецы-братья.
Собственно там ему и место.
Я сравниваю уровень твоих ответов. Маны я читаю, но это не маны по перлу :)
Спасибо что в chatgpt еще не послал :)
Там привели не полную конструкцию. Должно быть:
Так понятнее?
А что это изменит? В каждом процессе все равно будет один поток.
То есть смотреть реализацию, вместо того чтобы посмотреть на сигнатуру метода? Очень эффективная методика :)
Для подобного perl хорошо подходит, но здесь он как раз играет на поле sed, awk и прочих shell утилит.
Нет никакой проблемы баланса с типизацией: современные компилируемые языки хорошо скриптуются, например, тот же C#.