Война фреймворков Java: весна и гибернация - PullRequest
28 голосов
/ 19 сентября 2008

Мои разработчики ведут гражданскую войну. В одном лагере они приняли Hibernate и Spring. В другом лагере они осудили фреймворки - хотя они рассматривают Hibernate.

Вопрос в том, есть ли какие-нибудь неприятные сюрпризы, слабости или ловушки, на которые новички Hibernate-Spring могут наткнуться?


PS: У нас есть библиотека DAO, которая не очень сложна. Я сомневаюсь, что он обладает богатством Hibernate, но он достигает какой-то зрелости (то есть он не был изменен в нескольких последних проектах, которые он включил).

Ответы [ 18 ]

1 голос
/ 19 февраля 2010

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

1 голос
/ 09 января 2009

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

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

1 голос
/ 19 сентября 2008

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

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

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

/ Ace

1 голос
/ 01 января 2009

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

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

1 голос
/ 24 сентября 2008

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

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

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

0 голосов
/ 19 сентября 2008

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

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

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

0 голосов
/ 19 сентября 2008

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

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

0 голосов
/ 19 сентября 2008

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...