Война Java Frameworks: Spring и Hibernate

Они осудили рамки?

Это безумие. Если вы не используете готовый фреймворк, вы создаете свой собственный. Это все еще фреймворк.

Я мало работал с Java, но я работал в больших группах разработчиков Java. У меня сложилось впечатление, что весна - это нормально. Но все были недовольны Hibernate. Половина команды, если бы спросили: «Если бы вы могли изменить что-то одно, что бы вы изменили?» и они бы сказали: «Избавьтесь от Hibernate.». Когда я начал изучать Hibernate, он поразил меня своей сложностью, но я не узнал достаточно (к счастью, я продвинулся), чтобы знать, оправдана ли сложность или нет (возможно, это потребовалось для решения некоторых сложных проблем).

Команда отказалась от Spring в пользу Guice, но это было больше похоже на политическое изменение, по крайней мере, с моей точки зрения и с точки зрения других разработчиков, с которыми я разговаривал.

Фреймворки - это не зло. даже Java SDK является фреймворком.

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

Если вы боретесь с кодом, который трудно отлаживать из-за непоследовательного использования базы данных, сложных механизмов кеширования или множества других причин. Hibernate добавит большую ценность. кроме кривой обучения (на которую у меня ушло около 1 месяца практической работы) не было никаких подводных камней, при условии, что у вас есть кто-то, кто объяснит вам основы.

У Hibernate есть причуды, но это потому, что проблема, которую он пытается решить, сложна. Каждый раз, когда кто-то жалуется на Hibernate, я напоминаю им обо всем скучном коде DAO, который им пришлось бы поддерживать, если бы они его не использовали.

Несколько советов:

• Hibernate не заменяет хороший дизайн базы данных. Схемы гибернации в порядке, но вам придется время от времени их настраивать
• В конце концов вам нужно будет понять, как Hibernate лениво загружает классы и как это влияет на вещи. Hibernate изменяет байт-код Java, и вам рано или поздно придется углубиться в глубину, хотя бы для того, чтобы объяснить, почему ссылки на объекты равны нулю.
• По возможности используйте аннотации.
• Найдите время, чтобы изучить методы настройки производительности Hibernate, они спасут вас в долгосрочной перспективе.

Я много занимался разработкой Spring / Hibernate. Со временем способ, которым люди использовали оба эти средства в сочетании, немного изменился. Оригинальный подход HibernateTemplate оказался трудным для отладки, поскольку он поглощает и обертывает в ином случае полезные исключения; поговорите с API Hiberante напрямую!

Продолжайте смотреть на сгенерированный SQL (настройте журнал разработки для отображения SQL). Наличие уровня абстракции для базы данных не означает, что вам больше не нужно думать на языке SQL; в противном случае вы не получите хорошей производительности.

Рассмотрим проект. Я выбирал iBatis вместо Hibernate в нескольких случаях, когда у нас были строгие требования к производительности, сложные устаревшие схемы или хорошие DBa, способные писать отличный SQL.

@slim - Я снова с тобой сегодня утром.

Звучит как классический случай Не изобретенный здесь синдром. Если им не нравится весна, им следует рассмотреть другие варианты, а не разворачивать свою собственную структуру (независимо от того, признают они это или нет). Guice приходит на ум как возможность. Также пикоконтейнер. Есть и другие, в зависимости от того, что вам нужно.

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

Spring - хороший инструмент, если вы знаете, как им правильно пользоваться.

Я бы сказал, что фреймворки - определенно хорошая вещь - как отмечали другие, вы не хотите изобретать велосипед. Spring содержит множество модулей, а это значит, что вам не придется писать так много кода. Не поддавайтесь синдрому «изобретено не здесь»!

Что касается Hibernate: очень хороший инструмент для приложений, который имеет дело с быстро меняющейся схемой базы данных, большим количеством таблиц, выполняет множество простых операций CRUD. Отчеты со сложными запросами обрабатываются гораздо хуже. Но в этом случае я предпочитаю смешивать JDBC или собственные запросы. Итак, для краткого ответа: я действительно считаю, что время, потраченное на изучение Hibernate, является хорошим вложением (они говорят, что он также соответствует стандартам EJB3.0 и JPA, но это не входило в уравнение, когда я оценивал его для своих личных нужд). использовать).

Насчет Spring ... см. Блог о желчи :)

Помните: фреймворки - это не серебряные пули, но и изобретать велосипед вам тоже не следует.

Это одна вещь (я мог вспомнить), в которую я попал, когда был в спячке. Когда вы удаляете (несколько) дочерних объектов из коллекции (в родительской сущности), а затем добавляете новые сущности в ту же коллекцию в одной транзакции без промывки в середине, Hibernate выполняет «вставку» перед «удалением». Если дочерняя таблица имеет уникальное ограничение в одном из своих столбцов, и вы ожидаете, что вы не нарушите его, поскольку вы уже удалили некоторые данные раньше (как и я), тогда будьте готовы разочароваться. Форум Hibernate предлагает:

2. Это был недостаток дизайна БД, редизайн;
3. очистить (или зафиксировать, если хотите) между удалениями и вставками;

Я не мог сделать и то, и другое, и в итоге пришлось настроить исходный код Hibernate и перекомпилировать. Это была всего одна строка кода. Но попытка найти эту строку равнялась примерно 27 чашкам кофе и 3 бессонным ночам.

Это всего лишь один пример проблем и причуд, с которыми вы можете столкнуться при использовании Hibernate без настоящего эксперта в вашей команде (эксперт: кто-то с адекватными знаниями о философии и внутренней работе Hibernate). Ваша проблема, решение, литр кофе и количество бессонных ночей могут отличаться. Но ты получил идею.

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

Конечно, у этого есть и обратная сторона. Прежде чем стать горячим разработчиком Hibernate, вы обнаружите, что пытаетесь вставить квадрат в круглое отверстие. Вы ЗНАЕТЕ, что вы хотите сделать и как вы должны это делать, до того, как Hibernate появился на свет, но поиск способа Hibernate может занять ... довольно много времени.

Тем не менее, для компаний, которые часто нанимают консультантов (которым необходимо понимать большой объем исходного кода за короткий промежуток времени), или где разработчики часто входят в систему и выходят из нее, или где вы просто не хотите делать ставку на то, что ваши ключевые разработчики будут оставайтесь навсегда и никогда не меняйте работу. Я думаю, что Hibernate и другие стандартные фреймворки - неплохая идея.

/Туз

Я всегда считал Hibernate немного сложным и трудным для изучения. Но поскольку JPA (Java Persistence API) и EJB (Enterprise Java Beans) 3.0 существует уже некоторое время, все стало намного проще, я предпочитаю аннотировать свои классы для создания сопоставлений через JavaDoc или XML. Проверьте поддержка в Hibernate. Дополнительным бонусом является то, что можно (но не без усилий) изменить структуру базы данных позже, если это необходимо. Я использовал OpenJPA с отличными результатами.

В последнее время я все больше и больше использую JCR (Java Content Repository). Мне нравится, как мои модули могут совместно использовать единое хранилище данных и что я могу позволить структуре и свойствам развиваться. Мне намного проще работать с узлами и свойствами, чем с отображением моих объектов в базе данных. Хорошая реализация - Зайчик.

Что касается Spring, в нем есть много функций, которые мне нравятся, но объем XML, необходимый для настройки, означает, что я никогда не буду его использовать. Вместо этого я использую Guice, и он мне очень нравится.

Подводя итоги, я хотел бы показать вашим сомневающимся разработчикам, как Hibernate облегчит их жизнь. Что касается Spring, я бы серьезно проверил, является ли Guice жизнеспособной альтернативой, а затем попытался бы показать, как Spring / Guice делает разработку лучше и проще.

Spring и Hibernate определенно облегчают жизнь. Начало работы с ними может занять немного времени вначале, но вы наверняка извлечете из этого пользу позже. Теперь XML заменяется аннотациями, вам также не нужно вводить сотни строк XML.

Вы можете использовать AppFuse, чтобы сократить время обучения: создайте приложение, изучите и адаптируйте его - и вперед.

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

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

Spring и Hibernate - это фреймворки, которые сложно освоить. Может быть, не стоит использовать их в проектах с сжатыми сроками, пока вы все еще пытаетесь понять фреймворки.

Преимущества фреймворков заключаются в том, чтобы попытаться предоставить платформу, позволяющую согласованным кодам быть продуктами. Исходя из своего опыта, вам будет полезно иметь разработчиков, имеющих опыт работы с фреймворками, устанавливая передовые методы.

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

Я использовал Hibernate несколько раз в прошлом. Каждый раз я сталкивался с крайними случаями, когда определение синтаксиса превращалось в поиск мусора через документацию, Google и старые версии. Это мощный инструмент, но плохо документирован (в последний раз я смотрел).

Что касается Spring, почти каждая вакансия, на которую я брал интервью или смотрела за последние несколько лет, связана со Spring, она действительно стала стандартом де-факто для Java / web. Его использование поможет вашим разработчикам стать более востребованными в будущем и поможет вам, поскольку у вас будет большой круг людей, которые поймут ваше приложение.

Написание собственного фреймворка соблазнительно, познавательно и весело. Не очень хорошие результаты.

Я согласен со многими сообщениями по этому поводу. Я широко использовал и то, и другое в самых разных условиях. Если бы я мог отменить дизайнерское решение, я бы использовал Hibernate. Мы фактически заложили в бюджет выпуск одного из наших продуктов, чтобы заменить Hibernate на iBatis и Spring-JDBC для лучшего из всех подходов. Я могу заставить нового разработчика быстрее освоить Spring-JDBC, Spring-MVC, Spring-Ioc и iBatis, чем если бы я просто поручил им Hibernate.

Hibernate слишком сложен для этого разработчика KISS. И небеса помогут вам с переходом в спящий режим, если ваш администратор базы данных видит сгенерированный SQL, который видит база данных, и отправляет вам обратно с оптимизированными версиями.

На мой взгляд, самым большим преимуществом Spring является то, что он поощряет и делает возможным более совершенные методы разработки, в частности слабую связь, тестирование и другие интерфейсы. Hibernate без Spring может быть очень болезненным, но оба вместе очень полезны.

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

В верхнем ответе упоминается, что Hibernate плохо документирован. Я согласен с тем, что интерактивное справочное руководство могло бы быть более полным. Однако книга «Сохранение Java с Hibernate», написанная авторами Hibernate, обязательна к прочтению для каждого пользователя Hibernate и очень полная.