Извлечение Hibernate / Mysql для MongoDB или Couch для веб-приложения Java / Spring / Tomcat

Question

У меня есть приложение, которое подвергается масштабной доработке, и я изучаю разные варианты - пускать «как есть», переделывать проект в другой среде или платформе и т. Д.

Когда я действительноПодумайте об этом, вот три основные вещи, которые мне действительно не нравятся в Java:

1. Запуск / остановка сервера при изменении контроллеров или других классов.Динамические языки - это огромная победа над Java.
2. Hibernate, исключения Lazyloading (особенно те, которые возникают при асинхронных вызовах службы или во время маршалинга JSON Джексона) и ORM в целом раздуваются.Hibernate сам по себе отвечает за медленное время запуска интеграции и безумно медленное время запуска приложения.
3. Глупость Java - противоречивые проблемы с загрузкой классов при запуске вашего приложения в вашей IDE по сравнению с Tomcat.Если вы решите эти проблемы, вы, скорее всего, больше их не увидите.Тем не менее, большинство из них на самом деле вызваны Hibernate, поскольку он настаивает на конкретной версии Antlr и т. Д.

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

Кто-нибудь из вас переработал Java-приложение на 50+ сущностей, чтобы использовать mongo или couch или подобную базу данных?Каким был опыт?Вы рекомендуете это?Сколько времени вам потребовалось, если у вас есть несколько отличных юнит / интеграционных тестов?Звучит ли идея лучше, чем она есть на самом деле?

Мое приложение могло бы принести пользу во многих областях, если бы я мог хранить документы.Это фактически открыло бы некоторые очень интересные и интересные функции для этого приложения.Однако мне нравится создавать динамические запросы для сложных поисков ... и мне говорят, что Couch не может этого сделать.

Я действительно зелен, когда дело доходит до баз данных NoSQL, поэтому любые советы по переносу (или не переносу) большого проекта Java / Spring были бы действительно полезны.Кроме того, если это хорошая идея, какие книги вы бы порекомендовали мне взять, чтобы я быстро освоился и действительно использовал их для этого приложения наилучшим из возможных способов?

Спасибо

Answer 1

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

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

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

Сохранение приложения, написанного на Java, на короткий срок кажется разумным, серьезное переписывание на другом языке определенно нарушит приемочные и интеграционные тесты.

Как и предлагал Джозеф, сделайте шаг из Hibernate в JPA.Это не должно стоить слишком много времени.И оттуда вы можете переключить серверную часть на другой способ хранения.Работать над тем, чтобы разделить проблемы.Выберите подходящую концепцию, некоторые предпочитают MVC, в то время как другие могут выбрать CQRS, а другие предпочитают другой стиль сегментации / разделения.

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

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

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

Итак, подведем итог коротко: маленькие шаги;потерять Hibernate и перейти к более абстрактным JPA;если Java становится глупой, то постепенно переключайтесь на умный язык.Ваша главная задача должна состоять в том, чтобы реструктурировать базовую часть кода без потери функциональности, имея в виду открытый дизайн, который в дальнейшем упростит добавление интересных и интересных функций.

Answer 2

Все эти точки обычно вызывают проблемы из-за некомпетентности, а не из-за гибернации или проблем с Java:

• кроме структурных изменений (добавление полей или методов), все изменения вКод Java в режиме отладки в горячем режиме позволяет сохранять и тестировать (без повторного развертывания).

• LazyInitializationException - проблема только для начинающих в спящем режиме.Есть много и четких решений, и вы найдете их с помощью простого поиска Google или SO.И вы всегда можете установить свои коллекции на fetch=FetchType.EAGER.Или вы можете использовать Hibernate.initialize(..) для инициализации отложенных коллекций.

• Для библиотеки совершенно нормально требовать определенную версию другой библиотеки (обратное будет подозрительным и неправильным).Если вы сохраните свой путь к классам чистым (например, используя maven или ivy), у вас не возникнет проблем с загрузкой классов.У меня никогда не было.

Теперь я предоставлю альтернативу. spring-data - это новый портфельный проект от springsource, который позволяет вам использовать свои сущности для нескольких магазинов NoSQL.

Answer 3

Ну, многое зависит от таких вещей, как "какие именно болевые точки у Hibernate?"(Я знаю, вы привели три примера ...)

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

NoSQL не собирается что-то исправлять, хотя хранилища документов могут, но есть шаг перехода, который вам придется пройти.

Важное замечание: Я работаю на продавца вэто пространство, которое объясняет мой опыт в этой области, а также смещение в следующем абзаце:

Я полагаю, что вы сосредоточены на проектах с открытым исходным кодом, хотя я бы предложил использовать коммерческий продукт:GigaSpaces (http://gigaspaces.com). Существует версия для сообщества, которая позволит вам переносить Java-объекты на основе JPA в модель документа (с помощью аннотации SpaceDynamicProperties); вы можете использовать JPA для написанного кода и медленно мигрировать в полностью документориентированная на вас модель, плюс сложные запросы - не проблема.