Стоит ли оставаться независимым от реализации?

У меня есть проект, над которым я сейчас работаю, использующий Tomcat, Spring 4, Spring Security, MySQL и JPA с Hibernate.

Я выбрал JPA с той точки зрения, что предполагается сделать замену базовой реализации поставщиков ORM беспроблемной или, по крайней мере, менее болезненной. Я бы сказал, что это умственное использование спецификации над реализацией (JAX-RS) является точкой зрения по умолчанию сообщества разработчиков Java.

Мне любопытно, стоит ли это делать на самом деле. Я уверен, что если бы я использовал Hibernate напрямую, я бы получил некоторую мощность, потому что я мог бы использовать функции, которые не являются частью основной спецификации JPA.

Часть моей заботы исходит от идеи ЯГНИ. По сути, я программирую в определенном стиле и стиле (использую JPA вместо Hibernate), чтобы в какой-то момент в будущем я мог поменять свою реализацию ORM. Я сильно сомневаюсь, что это когда-нибудь случится в течение срока службы продукта, поэтому я прилагаю усилия к тому, что я, вероятно, никогда не получу.

о чем ты думаешь? Стоит ли «программирование на интерфейс», когда дело доходит до таких вещей, как JPA? Вы когда-нибудь меняли всю реализацию ORM в продукте? Удалось ли вам когда-нибудь полностью избежать абстракции от утечки JPA? У меня лично уже есть один собственный вызов SQL (для очистки таблиц базы данных), и есть кое-что, с чем я хотел бы познакомиться, это встроено в спецификацию JPA (префиксы get / set для ваших методов и разница между MEMBER OF / IN, которая только привязывает себя к базовой реализации, даст мне шанс избежать.

так что когда-нибудь в будущем я смогу поменять свою реализацию ORM. Я сильно сомневаюсь, что это когда-нибудь случится в течение срока службы продукта, поэтому я прикладываю усилия к тому, что я, вероятно, никогда не получу

По моему опыту, типичный корпоративный проект никогда не менялся:

1. База данных
2. ORM
3. язык

Я не знаю цифр, но процент двухуровневых приложений, которые я видел, реализующих и затем изменяющих одну из этих вещей, вероятно, будет меньше 10%. Если это происходит, это происходит редко, и обычно это происходит в течение первых 2-3 месяцев проекта, когда люди все еще находятся в режиме обнаружения. Большинство систем, которые я знаю, все еще работают на своих оригинальных платформах спустя 8-10 лет.

Вы хотите узнать, что я видел чаще, чем заменять ORM? Полное удаление ORM для перехода на SQL из-за проблем с производительностью. Так что не важно, что, в таком случае, ты собираешься переписывать.

Насколько реализация независима, это миф. Это на самом деле сводится к тупости Поэтому мой подход заключается в том, чтобы охватить слой данных. Сделайте это первоклассной частью вашего языка и дизайна. Это делает для более счастливых, более успешных проектов.

стоит ли оно того?
Это будет полностью зависеть от приложения.
Если вы пишете внутреннюю заявку для одной компании, забудьте об этом. Эта база данных переживет заявку на годы, возможно, десятилетия.
Если, конечно, вам не дали понять с самого начала, что базу данных планируется заменить чем-то другим в ближайшем будущем.
Если вы пишете его для продажи клиентам, у которых могут быть разные механизмы баз данных, И требования таковы, что предполагается поддерживать несколько механизмов баз данных, ТОГДА это имеет смысл.

Тогда для большинства людей, пишущих приложения на Java, это не имеет значения.

Из моего опыта: нет, это не стоит в случае JPA / Hibernate.

Стоит ли «программирование на интерфейс», когда дело доходит до таких вещей, как JPA?

Это так, но не имеет ничего общего с JPA. Вы можете сделать «программирование на интерфейсы» Hibernate. Речь идет не о сокрытии фреймворка под стандартом, а о SOLID .

Вы когда-нибудь меняли всю реализацию ORM в продукте?

Да и нет. Один из продуктов нашей компании частично перешел с Hibernate на jOOQ (который не имеет ничего общего с JPA). Это не был «типичный корпоративный проект», о котором упоминал @codenheim, поэтому обмен был возможен.

Я не вижу смысла менять Hibernate на другой совместимый с JPA ORM.

Удалось ли вам когда-нибудь полностью избежать абстракции от утечки JPA?

Нет. Это невозможно, потому что JPA и Hibernate очень сложны. И вам все равно придется иметь дело с проблемами производительности и недостатками дизайна Hibernate.

Я бы сказал, что рискуя звучать противоположно, да, оно того стоит. И это не так.

Проблема заключается не столько в переключении вашего ORM или провайдера базы данных как такового. Это скорее вопрос разделения интересов и поддержания гибкости.

Как только вы начинаете полагаться на некоторые детали реализации библиотеки, вы начинаете создавать более глубокие и глубокие проблемы.

Если вы знаете, что ваша реализация ORM - Hibernate, эти знания начинают просачиваться по всей архитектуре вашего приложения. И всякий раз, когда появляется новая технология, которая вытесняет Hibernate или JPA так тщательно, как Hibernate по отношению к тому, что было до этого, вы обнаруживаете, что зависимости стали намного глубже, чем вы ожидали.

Гораздо лучше убрать всю заботу о сохранении вашей модели где-нибудь в стороне, где все тонкости работы с базами данных и транзакциями и так далее, могут быть легко проигнорированы остальной частью приложения. В этом удаленном темном углу вы можете связать себя узлами по конкретным деталям реализации, если хотите - это больше не имеет значения.

Проблема с независимостью от реализации заключается в том, что вы, будучи разработчиком, будете тратить время в любом случае.

Я написал несколько проектов, которые мы потратили много времени на написание интерфейса, которые затем никогда не использовались по-новому, никогда не конвертировались и просто использовались «как есть» в течение многих лет.

Я также потратил кучу времени на конвертацию программного обеспечения, которое никто даже не ожидал конвертировать.

Единственное реальное наблюдение, которое я должен сделать, - то, что первое намного менее болезненно.