Я не очень понял, о какой +1 реализации какого интерфейса речь. И я не сторонник отличной чистой архитектуры. Я люблю, что хоть немного грязи было, но не полная стерильность ))
Позволю себе еще одно объяснение по поводу моего отношения к ORM и кодогенерации. Чтоб не плодить холивары в нескольких местах: Если проект достаточно сложный и долгоживущий, развивающийся, рано или поздно но возникает необходимость в ручном написании и вызове каких-то запросов. С большой вероятностью возникает. Возникает потому, что нужно реализовать какую-то фичу или минимизировать время и количество обращений к БД - мало ли. И вот тут приходится обходить ORM и кодогенерацию. Сочетать же несколько инструментов одновременно для работы с БД конечно можно, но мне не хочется. Мне импонирует строгость и единообразие - меньше когнитивная нагрузка при работе с кодом проекта. Я не утверждаю что мой подход единственно верный. Но думаю, он имеет право на жизнь наравне с другими ).
Мне кажется это бесконечный спор ). Самое главное - sqlc же и модели генерирует? Я предпочитаю использовать по возможности одну модель для одной сущности для всех слоёв. По этой причине генерация моделей мне никак не подойдет. Второстепенное - Когда я пишу метод, вызывающий запрос к БД ручками, всё под моим контролем. Я могу использовать все 100% возможностей, которые дает мне драйвер СУБД так, как мне нравится. Кодогенерация отнимает у меня эту свободу. JFI: Я не утверждаю, что использование sqlc - плохо. Отнюдь. Но подходы могут быть разные. И у каждого свои плюсы и минусы. Каждый выбирает то, что ему больше по душе. Идеальных решений нет.
Я не про нюансы выполнения функций, я про наличие/отсутствие аналогичных функций. И никто не заставляет использовать какие-то уникальные фичи конкретной СУБД. Можно писать запросы, не используя уникальную специфику. ОРМ априори не подпускает вас к низкому уровню. И если идеологически это хорошо, то практически, если у вас хайлоад и вы ходите максимально оптимизировать работу с БД - он вам не позволит этого сделать. А как показывает практика, рано или поздно такая потребность возникает. И потом люди локти кусают.
Ну насчет медленнее и хуже - приведите аргументы, прежде чем клеить ярлыки ). Почему я не хочу использовать кодогенерацию, я уже писал. Я ж не навязываю своё мнение.
Ну если менять СУБД каждый год... То конечно ). Переписать имплементацию слоя репозитория раз в 10 лет - не криминально поверьте. Особенно если запросы хранятся отдельно от кода. Но мучится все эти 10 лет с минусами, вызванными абстрагированием от СУБД - тоже такое себе. Впрочем - зависит всё от контекста. И к слову, однотипные СУБД принципиально не отличаются по функционалу. 99% всего что можно делать в MS SQL сделаете и в Postgres легко. Я про SQL код.
Верно, согласен. Но на мой взгляд минусы перевешивают плюсы. В реальной жизни обходиться только ОРМ получится только для сферического коня в вакууме. Как концепция - классно. Но на практике - больно. ИМХО...
Согласен с вами. Но я за то, чтобы использовать один инструмент везде и единообразно. Зачем тащить билдер, если простые запросы написать просто? ИМХО - он лишний. Или чистый SQL или - билдер. Не вижу никакой пользы от смешивания - только лишняя зависимость, лишний код. Это - только моё личное мнение ) Чистый SQL дает полную свободу и весь диапазон функциональных возможностей.
не, это немного разные вещи всё-таки. А главное - в первом случае нет вариантов. Если только не сменить язык программирования. Компилируемый код всегда нужно компилировать. А тут - есть выбор - юзать генерацию или нет.
Билдеры и ОРМ-ы кажется удобными на старте, пока не появились специфические задачи/требования. А потом - это будет боль, мне кажется. Ну и бойлерплейт конечно.
Безусловно. Но я предпочитаю сам писать SQL-код. Я уже описывал здесь свои аргументы.
Я не очень понял, о какой +1 реализации какого интерфейса речь.
И я не сторонник отличной чистой архитектуры. Я люблю, что хоть немного грязи было, но не полная стерильность ))
Спасибо. Да, давно собираюсь.
Честность за честность: а я не имел живого опыта работы с ней )
Позволю себе еще одно объяснение по поводу моего отношения к ORM и кодогенерации. Чтоб не плодить холивары в нескольких местах:
Если проект достаточно сложный и долгоживущий, развивающийся, рано или поздно но возникает необходимость в ручном написании и вызове каких-то запросов. С большой вероятностью возникает. Возникает потому, что нужно реализовать какую-то фичу или минимизировать время и количество обращений к БД - мало ли. И вот тут приходится обходить ORM и кодогенерацию.
Сочетать же несколько инструментов одновременно для работы с БД конечно можно, но мне не хочется. Мне импонирует строгость и единообразие - меньше когнитивная нагрузка при работе с кодом проекта.
Я не утверждаю что мой подход единственно верный. Но думаю, он имеет право на жизнь наравне с другими ).
Мне кажется это бесконечный спор ).
Самое главное - sqlc же и модели генерирует? Я предпочитаю использовать по возможности одну модель для одной сущности для всех слоёв. По этой причине генерация моделей мне никак не подойдет.
Второстепенное - Когда я пишу метод, вызывающий запрос к БД ручками, всё под моим контролем. Я могу использовать все 100% возможностей, которые дает мне драйвер СУБД так, как мне нравится.
Кодогенерация отнимает у меня эту свободу.
JFI: Я не утверждаю, что использование sqlc - плохо. Отнюдь. Но подходы могут быть разные. И у каждого свои плюсы и минусы. Каждый выбирает то, что ему больше по душе. Идеальных решений нет.
highload highload-у рознь )
Я не про нюансы выполнения функций, я про наличие/отсутствие аналогичных функций. И никто не заставляет использовать какие-то уникальные фичи конкретной СУБД. Можно писать запросы, не используя уникальную специфику.
ОРМ априори не подпускает вас к низкому уровню. И если идеологически это хорошо, то практически, если у вас хайлоад и вы ходите максимально оптимизировать работу с БД - он вам не позволит этого сделать. А как показывает практика, рано или поздно такая потребность возникает. И потом люди локти кусают.
Ну насчет медленнее и хуже - приведите аргументы, прежде чем клеить ярлыки ). Почему я не хочу использовать кодогенерацию, я уже писал. Я ж не навязываю своё мнение.
Ну, не всем нравится дополнительная кодогенерация )
Ну если менять СУБД каждый год... То конечно ). Переписать имплементацию слоя репозитория раз в 10 лет - не криминально поверьте. Особенно если запросы хранятся отдельно от кода. Но мучится все эти 10 лет с минусами, вызванными абстрагированием от СУБД - тоже такое себе. Впрочем - зависит всё от контекста. И к слову, однотипные СУБД принципиально не отличаются по функционалу. 99% всего что можно делать в MS SQL сделаете и в Postgres легко. Я про SQL код.
Верно, согласен. Но на мой взгляд минусы перевешивают плюсы. В реальной жизни обходиться только ОРМ получится только для сферического коня в вакууме. Как концепция - классно. Но на практике - больно. ИМХО...
Согласен с вами. Но я за то, чтобы использовать один инструмент везде и единообразно. Зачем тащить билдер, если простые запросы написать просто? ИМХО - он лишний. Или чистый SQL или - билдер. Не вижу никакой пользы от смешивания - только лишняя зависимость, лишний код. Это - только моё личное мнение )
Чистый SQL дает полную свободу и весь диапазон функциональных возможностей.
Ну так делать не надо, если только нет на то очень веских причин ))))
а зачем тогда билдер? Почему не писать запросы руками? См https://habr.com/ru/articles/977046/comments/#comment_29260880
не, это немного разные вещи всё-таки. А главное - в первом случае нет вариантов. Если только не сменить язык программирования. Компилируемый код всегда нужно компилировать. А тут - есть выбор - юзать генерацию или нет.
В секунду чтение в мапу из памяти (ambedded FS)?!! )))
Да это микросекунды. Готов поставить эксперимент.
Ты прав! Вот же блин всё время путаю. Дурацкие названия.. ))
Билдеры и ОРМ-ы кажется удобными на старте, пока не появились специфические задачи/требования. А потом - это будет боль, мне кажется. Ну и бойлерплейт конечно.
Ну а про ORM-ы лучше вообще промолчу ))))