Вы в целом правы. Но давайте будем честны: все эти практики активно применялись очень давно и задолго до Мартина.
Я начал карьеру в 1996 году и на той, самой первой своей работе в совсем небольшой фирме применялся VSS, существовал style gгide и требования к именованиям в коде, были автоматические тесты (в кустарном виде, да. Но были) и даже то, что сейчас называется code review было. Lotus Notes использовался в качестве, вы не поверите, системы с тикетами для раздачи и контроля выполнения задач. (что-то типа Jira на минималках)
Да и не все было так уже примитивно. Вторая поливина 90x это куча IDE c GUI которые много чего могли, это инструменты RAD вроде Delphi или Gupta SqlWindows. Инструментарий был, его было не мало и оно все активно развивалось и улучшалось.
СVS и предок VSS существовали уже в самом начале 90x. Концепция юнит-тестов корнями вообще уходит куда-то в конец 70x и активно пропагандировалась Кентом нашим Беком чуть ли не с конца 80x.
Где-то в самом начале 2000x я попал в мир Java и сразу: CVS, Ant, JUnit (да, он уже существовал), стандарт форматирования прямо от разработчиков ЯП, дизайн паттерны (знаменитая книжка тогда уже вышла несколько лет как, ee даже на русский перевили уже в 1999 году) и вот это вот все.
Т.е. все практически упомянутые практики были широко известны черт знает с каких времен.
Да инструменты, были гораздо примитивнее. Hudson/Jenkins появился позже: в моих первых проектах, то что сейчас называется CI/CD выглядело как набор самописанных bash-скриптов которые гонялись по cron. Но это было! Да, не было еще общепринятой терминологии для каких-то штук. Но сами практики не были никаким откровением ни для кого в профессиональной разработке и были повсеместно распространенны.
Проблема со всеми этими модными акронимами в том что они бессмыслены в отрыве от контекста.
Ну вот "делай просто". А что значит "просто"?
У нас куча подходов, техник и т.п. которые сложны просто в силу своей природы.
Например реактивщина, многозадачность, многозвенные транзакции и т.д. и т.п. - это не простые темы, c этим не просто работать. И что теперь? Не будем применять никогда потому что, да, сложно?
IMHO: Нету никаких всегда работающих принципов, которым можно бездумно следовать и жизнь счастливо.
На самом деле, за 30 лет подход к разработке изменился очень сильно. Да и то что мы разрабатываем - тоже.
Новых парадигм конечно не появилось (кажется), но скажем функциональное программирование 30 лет назад было очень нишевый штукой, а сейчас эта парадигма поддерживается в каждом втором маинстримном ЯП.
Нам доступно радикально другое железо (например многоядерности 30 лет назад не было в принципе, не было смартфонов, не было ультраскоросного интернета). Это все оказывает огромное влияние в том числе и на то как мы разрабатываем и что мы разрабатываем.
Если вы посмотрите, например, на первые версии Java (как раз 30 лет назад появилась) и то что мы имеем сейчас: это выглядит почти как другой язык.
Многие вещи которые казались перспективным будущим просто вымерли как мамонты (яркий пример CORBA, а я еще помню сколько было писка вокруг неё как раз в районе самого начала 2000х).
Короче я мог бы многое написать о том, что сдохло а что появилось потому как раз лет примерно 30 в этой профессии. У меня есть много лет опыта в технологиях, методологиях и даже ЯП, которые сейчас почти нифиг никому и не для чего не сдались.
Но моя мысль в том что как раз в разработке софта мир меняется настолько быстро, что опыт 10-летней давности это на половину уже бесполезный опыт. А 30-летней давности - на 90%. IMHO.
Я вам больше скажу: все книжки Мартина это популизм чистой воды. Субъектившина. А если он вдруг пишет книжку более практическую (как евоная книжка по C# например) то совсем ерунда выходит.
А так то да, умный человек. Так на пустом месте распиариться - это недюженый талант.
Описываемый автором подход полностью согласуется с моим личным опытом. Спасибо ему что хорошо сформулировал.
Когда люди обсуждают Clean Code, часто забывают что это по сути субъективное мнение/опыт конкретных персонажей. Нету в мире ничего чисто белого и чисто черного. Нельзя Clean Code брать как методичку "делать всегда так и только так". Это полезно принимать во внимание в виде "ок, посыл понял, буду учитывать", но не более того.
Да, очень большие методы - это как правило не хорошо.
Но вся кодовая база разбитая ну кучи супер мелких методов и классов - это ровно так же, как правило, не хорошо (читать, понимать и поддерживать такой код тоже... такое себе).
Нету никакого общего правила как быть в конкретной ситуации. И быть не может.
Проблема в то что люди берут какой-то распиаренный термин и носятся с ним, как с высшим откровением. Не сильно задумываясь. Не пытаясь критику поискать/почитать.
Упомянутое мной поведение спецификацией JPA просто требует: "If the autoApply element is specified as true, the persistence provider must automatically apply the converter to every mapped attribute of the specified target type belonging to any entity in the persistence unit... ". (с) Jakarta Persistence ver 3.2
На всякий случай я проверил документацию Hibernate и там это подтверждается: "AttributeConverter can be applied globally for @Converterr( autoApply=true ))..." (c) Hibernate ORM 6.1.7.Final User Guide
Т.е. если в Hibernate это не работает то "ха-ха": самое время репортить им критический баг. :)
Но наверняка, да, проблема не в Hibernate а в вашей конфигурации, фреймворке и т.п. Я бы постарался разобраться.
Для использования в Hibernate это делается аналогичным образом, но вместо отдельного типа данных используется аннотация конвертера над полем сущности.
Не очень понятно что имеется ввиду.
Вы сделали обычный JPA конвертер с autoApply = true. Это означает, что конвертер будет автоматически применятся ко всем полям всех сущностей с соответствущим типом. Никакая аннотация на полем сущности не нужна: была бы нужна если бы было autoApply = false. И это работает совершенно одинаково что с Hibernate, что с EclipseLink.
Сильно все перемешано. Давайте определимся в терминах немного.
Spring Data - это просто абстрактный слой для доступа к данным. Не только к RDBMS. C ним нет никаких проблем.
JPA - спецификация для работы с RDBMS. Часть спецификаций JEE. К Spring не имеет никакого отношения. Вся критика в статье по большей части относится именно к JPA.
Híbernate - на данный момент, это одна из реализаций JPA (JPA-runtime). Нужно заметить что это не единственная реализация (есть еще EclipseLink, OpenJPA, может что-то еще). Понятно что в сторону от спецификации её реализация уходить не может (ну, почти). Так что Híbernate критиковать особо не за что. Более того, на данный момент это пожалуй лучший JPA-runtime из всех. К слову: хороший стиль при работе с JPA это нигде не опускаться до рантайма, в коде не должно быть никаких зависимостей от конкретного рантайма. В идеале. Почти никогда не достижимом идеале.
Spring Data JPA - по сути просто адаптер: Spring Data для JPA. Опять же с ним нет никаких особых проблем. Даже наоборот: он жизнь упрощает.
Что не так с JPA?
Это ORM. ORM cам по себе не плох и не хорош. Это просто "технология программирования". У этого подхода есть плюсы, но есть и жирные минусы (object-relational impedance mismatch, N+1 и т.д.). Споров вокруг много и не просто так: как минимум 3 очень популярных Java библиотеки для упрощения работы с RDBMS которые не ORM (Jooq, JDBi, MyBatis) как бы намекают.
JPA старая тема. И, как и некоторые другие спеки из JEE, основана на JavaBeans: мутабельность, конструктор без параметров, get/set - это все оттуда. Подход устаревший, мягко говоря. Так сейчас стараются не делать. Но... обратная совместимость с килотоннами софта написанного на JPA за 20 лет. Этот груз JPA тянет с собой и навязывает разработчикам, нравится вам это или нет. И это жирный минус.
Но пусть. Вышеидущие пункты это серая зона. Вкусовщина в какой-то степени. Но самое главное - JPA это огромная и очень сложная спека. 600 страниц документации - это только спека и это вершинка айсберга. Спека ограниченная, кое-где не доконца однозначная, кое-что отдающая на откуп рантайму. Рантаймы как следствия подъезжают со своей докой не меньшего размера, c сотнями расширений (некоторые из которых критически полезны), с многочисленными особенностями конфигурации. Рантаймы, кстати, могут кое-где спеку нарушать или уходить в серую зону там, где спеку можно понять двояко. Многочисленные способы выстрелить себе в ногу в совершенно тривиальном коде (например в реализации equals). Различные API и способы сделать одно и тоже, которые внезапно могут выдавать разный результат. Вопросы с производительностью. Море багов (в EclipseLink, например, есть баги которые не фиксятся по 10 лет. :( ) Собственно сам рантайм - это много мегабайт дополнительных JARов в вашем приложении... Нужно много-много опыта и специфических знаний, чтобы умело с этим всем работать.
В реальности есть большой вопрос оправдана ли вся эта дополнительная сложность в конкретном приложении. Бывают, это правда, сценарии где оно действительно стоит того. Но сильно, сильно реже чем принято думать. JPA совершенно точно не лучший выбор "по умолчанию", но как-то так сложилось что это именно что выбор по умолчанию в Java-мире. Часто люди просто даже не задумываются что альтернативы есть и их много.
Вторая половина 80-x это уже эпоха 32-bit: i386, i486, SPARC V7, ARM2/ARM3, Motorola 68020/68030, MIPS R3000, Zilog Z80000, NEC V60. Это всё 32-bit CPU из того времени и наверняка не полный список.
Подозреваю что уже тогда были и интегрированные FPU, кэши и даже brach prediction: все это было, например, у IBM POWER1 который вышел в 1990 и я сомневаюсь что он был прям первым таким.
Вот многоядерность и SMP появилось сильно позже. Самый конец 90-x/начало 2000-x, да.
Мне кажется что в нынешних реалиях SerialGC это не столько про экономию памяти, сколько про работу в ситуации когда JVM доступно только одно процессорное ядро.
Известно что JVM, по умолчанию в такой ситуации, запускает именно SerialGC, видимо потому, что все остальные GC не дают никаких выигрышей, если для нужных им дополнительных потоков у окружения доступных процессорных ядер нету.
И это не редкая ситуация в реальности, когда люди запускаю приложение в какой-нить виртуальной ноде с единственным доступным процессорным ядром. А потом удивляются.
А память... я сильно сомневаюсь, что кто-то реально живет с SerialGC чтобы память экономить.
Aх да, и пока люди втыкают мне минуса в предыдущий коммент я таки накину ещё:
Предмет моей личной ненависти к "дядюшке" это то, что именно он ввел в обиход акроним SOLID. Эта эпичная малоприложимая к реальности хрень, в которую буковки подбирали, чтобы выглядело красиво.
Именно. Вы знаете хоть один значимый продукт/сервис/библиотеку/фреймфорк/алгоритм за которым стоял бы Мартин хотя бы как "один из"? Может он коммитер в каких-нить больших делах типа Java/Linux/PostgreSQL ? Может он участвует в развитии серьезных стандартов или спецификаций? Я честно пытался что-то найти: нету ничего.
Чувак известен сомнительными книгами от которых больше вреда чем пользы (а для начинающих так вообще один только вред), и тем что учит других как программировать, и тем что одним из первых вписался в Agile-движняк (отдельная сковорода ему в аду за это).
Насчет "проще и короче" это, скажем прямо, далеко не всегда так.
Но дело не только в этом. А в том, что ради ничтожного объема кода связанного с DB, вы добавляете в приложение огромный JPA-runtime (~6-8 Mb) о котором просто необходимо много чего знать (иначе выстрел в ногу почти неминуем); платите некоторой потерей производительности и сильно возросшей сложностью.
Если уж так страшно иметь дело с чистым JDBC, то есть сильно более лекговестные и предсказуемые библиотеки, например JDBi или тот же Spring JdbcTemplate.
Проекты для которых праимущества JPA перевешивают связанные с ним сложности и накладные расходы они бывают, но сильно реже чем кажется.
JPA это совершенно точно не "лучший выбор по умолчанию". Особено для небольших приложений.
Любая критика JPA в своей сути о том, что это экстремально сложная спецификация.
К которой добавляются экстремально сложные реализации, которые не во всем спецификации следуют и к тому же тащат с собой сотни расширений.
И как вишенка на торте: дополнительные библиотеки Spring Data, DeltaSpike Data и т.п.
Всё это вместе: тысячи страниц документаций, сотни багов, пачки "воркараундов" ...
Нужны годы, буквально, опыта чтобы умело с этим работать и в любовно расставленные повсеместно ловушки не попадать.
Вот вы целую хорошую статью написали по сути о том, как не попасть в засаду выполняя тривиальный запрос.
А в соседней статье целый опус о том как не просто реализовать equals(!) для Entity.
Я о 10-ках подобных нюансов JPA мог бы рассказать, и это при том, что я убежден: за много лет я сталкивался я с каким-то небольшим подмножеством проблем.
И люди тащат этого монстра в микросервис с 5-ю запросами к базе.
Микросервисы это по определению - архитектурный паттерн распределенного приложения.
И да, что часто забывают это то, что "распределенное приложение" это всегда сложно. Независимо от того микросервисы это или какие-нить CORBА/RPC/SOAP или еще что там у нас в прошлом было модно.
Это все уже давно не новый опыт и всегда одни и те же трудности: отладка, логи, сложный рефакторинг, многошаговые транзакции, производительность, сеть и трафик и т.д. и т.п. Специфические засады поджидают где угодно и часто бывают крайне сложно уловимы.
Здравый смысл подсказывает, что во весь этот ад лезть изначально и по умолчанию - такая себе идея. Нужно хорошо осознавать что полученные преимущества в конкретной ситуации перевешивают радикально возросшую техническую сложность.
p.s. Собственно даже евангелисты типа Фаулера давно говорят что начинать прям с микросервисов не надо: Monolith First типа...
Не могу удержаться чтобы не запостить здесь парочку наиболее известных статей с критикой DIP:
https://naildrivin5.com/blog/2019/12/02/dependency-inversion-principle-is-a-tradeoff.html
https://dannorth.net/cupid-the-back-story/
Вы в целом правы. Но давайте будем честны: все эти практики активно применялись очень давно и задолго до Мартина.
Я начал карьеру в 1996 году и на той, самой первой своей работе в совсем небольшой фирме применялся VSS, существовал style gгide и требования к именованиям в коде, были автоматические тесты (в кустарном виде, да. Но были) и даже то, что сейчас называется code review было. Lotus Notes использовался в качестве, вы не поверите, системы с тикетами для раздачи и контроля выполнения задач. (что-то типа Jira на минималках)
Да и не все было так уже примитивно. Вторая поливина 90x это куча IDE c GUI которые много чего могли, это инструменты RAD вроде Delphi или Gupta SqlWindows. Инструментарий был, его было не мало и оно все активно развивалось и улучшалось.
СVS и предок VSS существовали уже в самом начале 90x. Концепция юнит-тестов корнями вообще уходит куда-то в конец 70x и активно пропагандировалась Кентом нашим Беком чуть ли не с конца 80x.
Где-то в самом начале 2000x я попал в мир Java и сразу: CVS, Ant, JUnit (да, он уже существовал), стандарт форматирования прямо от разработчиков ЯП, дизайн паттерны (знаменитая книжка тогда уже вышла несколько лет как, ee даже на русский перевили уже в 1999 году) и вот это вот все.
Т.е. все практически упомянутые практики были широко известны черт знает с каких времен.
Да инструменты, были гораздо примитивнее. Hudson/Jenkins появился позже: в моих первых проектах, то что сейчас называется CI/CD выглядело как набор самописанных bash-скриптов которые гонялись по cron. Но это было! Да, не было еще общепринятой терминологии для каких-то штук. Но сами практики не были никаким откровением ни для кого в профессиональной разработке и были повсеместно распространенны.
Проблема со всеми этими модными акронимами в том что они бессмыслены в отрыве от контекста.
Ну вот "делай просто". А что значит "просто"?
У нас куча подходов, техник и т.п. которые сложны просто в силу своей природы.
Например реактивщина, многозадачность, многозвенные транзакции и т.д. и т.п. - это не простые темы, c этим не просто работать. И что теперь? Не будем применять никогда потому что, да, сложно?
IMHO: Нету никаких всегда работающих принципов, которым можно бездумно следовать и жизнь счастливо.
На самом деле, за 30 лет подход к разработке изменился очень сильно. Да и то что мы разрабатываем - тоже.
Новых парадигм конечно не появилось (кажется), но скажем функциональное программирование 30 лет назад было очень нишевый штукой, а сейчас эта парадигма поддерживается в каждом втором маинстримном ЯП.
Нам доступно радикально другое железо (например многоядерности 30 лет назад не было в принципе, не было смартфонов, не было ультраскоросного интернета). Это все оказывает огромное влияние в том числе и на то как мы разрабатываем и что мы разрабатываем.
Если вы посмотрите, например, на первые версии Java (как раз 30 лет назад появилась) и то что мы имеем сейчас: это выглядит почти как другой язык.
Многие вещи которые казались перспективным будущим просто вымерли как мамонты (яркий пример CORBA, а я еще помню сколько было писка вокруг неё как раз в районе самого начала 2000х).
Короче я мог бы многое написать о том, что сдохло а что появилось потому как раз лет примерно 30 в этой профессии. У меня есть много лет опыта в технологиях, методологиях и даже ЯП, которые сейчас почти нифиг никому и не для чего не сдались.
Но моя мысль в том что как раз в разработке софта мир меняется настолько быстро, что опыт 10-летней давности это на половину уже бесполезный опыт. А 30-летней давности - на 90%. IMHO.
Я вам больше скажу: все книжки Мартина это популизм чистой воды. Субъектившина. А если он вдруг пишет книжку более практическую (как евоная книжка по C# например) то совсем ерунда выходит.
А так то да, умный человек. Так на пустом месте распиариться - это недюженый талант.
Описываемый автором подход полностью согласуется с моим личным опытом. Спасибо ему что хорошо сформулировал.
Когда люди обсуждают Clean Code, часто забывают что это по сути субъективное мнение/опыт конкретных персонажей.
Нету в мире ничего чисто белого и чисто черного.
Нельзя Clean Code брать как методичку "делать всегда так и только так".
Это полезно принимать во внимание в виде "ок, посыл понял, буду учитывать", но не более того.
Да, очень большие методы - это как правило не хорошо.
Но вся кодовая база разбитая ну кучи супер мелких методов и классов - это ровно так же, как правило, не хорошо (читать, понимать и поддерживать такой код тоже... такое себе).
Нету никакого общего правила как быть в конкретной ситуации. И быть не может.
Проблема в то что люди берут какой-то распиаренный термин и носятся с ним, как с высшим откровением. Не сильно задумываясь. Не пытаясь критику поискать/почитать.
Ну, смотрите.
Упомянутое мной поведение спецификацией JPA просто требует: "If the autoApply element is specified as true, the persistence provider must automatically apply the converter to every mapped attribute of the specified target type belonging to any entity in the persistence unit... ". (с) Jakarta Persistence ver 3.2
На всякий случай я проверил документацию Hibernate и там это подтверждается: "AttributeConverter can be applied globally for
@Converterr( autoApply=true ))..." (c) Hibernate ORM 6.1.7.Final User GuideТ.е. если в Hibernate это не работает то "ха-ха": самое время репортить им критический баг. :)
Но наверняка, да, проблема не в Hibernate а в вашей конфигурации, фреймворке и т.п. Я бы постарался разобраться.
Не очень понятно что имеется ввиду.
Вы сделали обычный JPA конвертер с autoApply = true. Это означает, что конвертер будет автоматически применятся ко всем полям всех сущностей с соответствущим типом. Никакая аннотация на полем сущности не нужна: была бы нужна если бы было autoApply = false. И это работает совершенно одинаково что с Hibernate, что с EclipseLink.
Что же вы древнейший инструмет такого рода не упомянули SoapUI. Он живее всех живых. :)
Сильно все перемешано. Давайте определимся в терминах немного.
Spring Data - это просто абстрактный слой для доступа к данным. Не только к RDBMS. C ним нет никаких проблем.
JPA - спецификация для работы с RDBMS. Часть спецификаций JEE. К Spring не имеет никакого отношения. Вся критика в статье по большей части относится именно к JPA.
Híbernate - на данный момент, это одна из реализаций JPA (JPA-runtime). Нужно заметить что это не единственная реализация (есть еще EclipseLink, OpenJPA, может что-то еще). Понятно что в сторону от спецификации её реализация уходить не может (ну, почти). Так что Híbernate критиковать особо не за что. Более того, на данный момент это пожалуй лучший JPA-runtime из всех. К слову: хороший стиль при работе с JPA это нигде не опускаться до рантайма, в коде не должно быть никаких зависимостей от конкретного рантайма. В идеале. Почти никогда не достижимом идеале.
Spring Data JPA - по сути просто адаптер: Spring Data для JPA. Опять же с ним нет никаких особых проблем. Даже наоборот: он жизнь упрощает.
Что не так с JPA?
Это ORM. ORM cам по себе не плох и не хорош. Это просто "технология программирования". У этого подхода есть плюсы, но есть и жирные минусы (object-relational impedance mismatch, N+1 и т.д.). Споров вокруг много и не просто так: как минимум 3 очень популярных Java библиотеки для упрощения работы с RDBMS которые не ORM (Jooq, JDBi, MyBatis) как бы намекают.
JPA старая тема. И, как и некоторые другие спеки из JEE, основана на JavaBeans: мутабельность, конструктор без параметров, get/set - это все оттуда. Подход устаревший, мягко говоря. Так сейчас стараются не делать. Но... обратная совместимость с килотоннами софта написанного на JPA за 20 лет. Этот груз JPA тянет с собой и навязывает разработчикам, нравится вам это или нет. И это жирный минус.
Но пусть. Вышеидущие пункты это серая зона. Вкусовщина в какой-то степени. Но самое главное - JPA это огромная и очень сложная спека. 600 страниц документации - это только спека и это вершинка айсберга. Спека ограниченная, кое-где не доконца однозначная, кое-что отдающая на откуп рантайму. Рантаймы как следствия подъезжают со своей докой не меньшего размера, c сотнями расширений (некоторые из которых критически полезны), с многочисленными особенностями конфигурации. Рантаймы, кстати, могут кое-где спеку нарушать или уходить в серую зону там, где спеку можно понять двояко. Многочисленные способы выстрелить себе в ногу в совершенно тривиальном коде (например в реализации equals). Различные API и способы сделать одно и тоже, которые внезапно могут выдавать разный результат. Вопросы с производительностью. Море багов (в EclipseLink, например, есть баги которые не фиксятся по 10 лет. :( ) Собственно сам рантайм - это много мегабайт дополнительных JARов в вашем приложении... Нужно много-много опыта и специфических знаний, чтобы умело с этим всем работать.
В реальности есть большой вопрос оправдана ли вся эта дополнительная сложность в конкретном приложении. Бывают, это правда, сценарии где оно действительно стоит того. Но сильно, сильно реже чем принято думать. JPA совершенно точно не лучший выбор "по умолчанию", но как-то так сложилось что это именно что выбор по умолчанию в Java-мире. Часто люди просто даже не задумываются что альтернативы есть и их много.
И даже более того.
Вторая половина 80-x это уже эпоха 32-bit: i386, i486, SPARC V7, ARM2/ARM3, Motorola 68020/68030, MIPS R3000, Zilog Z80000, NEC V60. Это всё 32-bit CPU из того времени и наверняка не полный список.
Подозреваю что уже тогда были и интегрированные FPU, кэши и даже brach prediction: все это было, например, у IBM POWER1 который вышел в 1990 и я сомневаюсь что он был прям первым таким.
Вот многоядерность и SMP появилось сильно позже. Самый конец 90-x/начало 2000-x, да.
Мне кажется что в нынешних реалиях SerialGC это не столько про экономию памяти, сколько про работу в ситуации когда JVM доступно только одно процессорное ядро.
Известно что JVM, по умолчанию в такой ситуации, запускает именно SerialGC, видимо потому, что все остальные GC не дают никаких выигрышей, если для нужных им дополнительных потоков у окружения доступных процессорных ядер нету.
И это не редкая ситуация в реальности, когда люди запускаю приложение в какой-нить виртуальной ноде с единственным доступным процессорным ядром. А потом удивляются.
А память... я сильно сомневаюсь, что кто-то реально живет с SerialGC чтобы память экономить.
А что скажете насчет https://github.com/postgrespro/rum ?
В том то и дело что нет. Это всё отнюдь не самоочевидно.
Вокруг "O" например вообще большие обсуждения: люди понимают по разному.
https://www.naildrivin5.com/blog/2019/11/14/open-closed-principle-is-confusing-and-well-wrong.html
А если накинуть контекст? не все ЯП знаете ли поддерживают OOП и как тогда быть например с "L"?
Даже "S" на практике далеко не всегда имеет смысл строго следовать.
Короче, в целом, это все субъективно и спорно. Мягко говоря.
Но раздули просто до какого-то библейского откровения.
Aх да, и пока люди втыкают мне минуса в предыдущий коммент я таки накину ещё:
Предмет моей личной ненависти к "дядюшке" это то, что именно он ввел в обиход акроним SOLID. Эта эпичная малоприложимая к реальности хрень, в которую буковки подбирали, чтобы выглядело красиво.
Вот вам подробное обсуждение в Подлодке, где в частности коснулись и того, почему с SOLID плохо почти все, от людей поумнее меня: https://www.youtube.com/watch?v=3deXOXWlHeg&t=6356s
Критических и дельных статей по теме в этих ваших интернетах полно. На любых языках.
Но кто услышит тихий голос разума на фоне рева толпы? (с)
Именно. Вы знаете хоть один значимый продукт/сервис/библиотеку/фреймфорк/алгоритм за которым стоял бы Мартин хотя бы как "один из"?
Может он коммитер в каких-нить больших делах типа Java/Linux/PostgreSQL ?
Может он участвует в развитии серьезных стандартов или спецификаций?
Я честно пытался что-то найти: нету ничего.
Чувак известен сомнительными книгами от которых больше вреда чем пользы (а для начинающих так вообще один только вред), и тем что учит других как программировать, и тем что одним из первых вписался в Agile-движняк (отдельная сковорода ему в аду за это).
Он популист от IT. Не читайте его и не слушайте.
Насчет "проще и короче" это, скажем прямо, далеко не всегда так.
Но дело не только в этом. А в том, что ради ничтожного объема кода связанного с DB, вы добавляете в приложение огромный JPA-runtime (~6-8 Mb) о котором просто необходимо много чего знать (иначе выстрел в ногу почти неминуем); платите некоторой потерей производительности и сильно возросшей сложностью.
Если уж так страшно иметь дело с чистым JDBC, то есть сильно более лекговестные и предсказуемые библиотеки, например JDBi или тот же Spring JdbcTemplate.
Проекты для которых праимущества JPA перевешивают связанные с ним сложности и накладные расходы они бывают, но сильно реже чем кажется.
JPA это совершенно точно не "лучший выбор по умолчанию". Особено для небольших приложений.
Любая критика JPA в своей сути о том, что это экстремально сложная спецификация.
К которой добавляются экстремально сложные реализации, которые не во всем спецификации следуют и к тому же тащат с собой сотни расширений.
И как вишенка на торте: дополнительные библиотеки Spring Data, DeltaSpike Data и т.п.
Всё это вместе: тысячи страниц документаций, сотни багов, пачки "воркараундов" ...
Нужны годы, буквально, опыта чтобы умело с этим работать и в любовно расставленные повсеместно ловушки не попадать.
Вот вы целую хорошую статью написали по сути о том, как не попасть в засаду выполняя тривиальный запрос.
А в соседней статье целый опус о том как не просто реализовать equals(!) для Entity.
Я о 10-ках подобных нюансов JPA мог бы рассказать, и это при том, что я убежден: за много лет я сталкивался я с каким-то небольшим подмножеством проблем.
И люди тащат этого монстра в микросервис с 5-ю запросами к базе.
Ну такое...
Спасибо за статью, познавательно.
Но JPA != Hibernate.
Как бы существуют и другие JPA runtime-ы (EclipseLink, OpenJPA)
И вообще говоря, не то чтобы это хороший стиль без острой необходимости, использовать runtime-зависимый код.
И как тогда реализовать корректно equals , без использования HibernateProxy?
Микросервисы это по определению - архитектурный паттерн распределенного приложения.
И да, что часто забывают это то, что "распределенное приложение" это всегда сложно.
Независимо от того микросервисы это или какие-нить CORBА/RPC/SOAP или еще что там у нас в прошлом было модно.
Это все уже давно не новый опыт и всегда одни и те же трудности: отладка, логи, сложный рефакторинг, многошаговые транзакции, производительность, сеть и трафик и т.д. и т.п. Специфические засады поджидают где угодно и часто бывают крайне сложно уловимы.
Здравый смысл подсказывает, что во весь этот ад лезть изначально и по умолчанию - такая себе идея. Нужно хорошо осознавать что полученные преимущества в конкретной ситуации перевешивают радикально возросшую техническую сложность.
p.s. Собственно даже евангелисты типа Фаулера давно говорят что начинать прям с микросервисов не надо: Monolith First типа...