Рассмотрение перемещающийся от Java/Spring MVC до Grails
Я в настоящее время использую Java и Spring (MVC) для создания веб-приложения, и я рассматриваю перемещение в Grails. Я ценил бы обратную связь/понимание на следующем:
У меня есть несколько контекстов приложения в текущем веб-приложении Java/Spring, которое я загружаю через web.xml ContextLoaderListener; действительно ли возможно иметь несколько контекстов приложения в Grails? Если, да, как?
Это веб-приложение экстенсивно использует успокоительный веб-сервис CXF, и текущее веб-приложение Java/Spring использует связанный клиент HTTP CXF. Я могу продолжить использовать (Java) CXF Клиент HTTP в Grails?
Я реализовал безопасность Spring с помощью пользовательской реализации UserDetails и UserDetailsService, действительно ли я могу снова использовать эти реализации в Grails, "как", или я должен повторно реализовать их?
Существует экземпляр, где я полагался на шаблон jdbc Spring (а не доступный ORM) и дополнительный источник данных, я определил в контексте приложения, действительно ли я могу снова использовать это в Grails?
Я планирую использование Знатока как инструмент управления проектами; есть ли какие-либо проблемы использования Знатока с Grails, где существует комбинация отличных и Java?
Править: Я полагаю, что перемещение в Grails делает разработку веб-компонента веб-приложения "быстрее", а-ля Ruby on Rails. Кроме того, я рассматриваю Grails, а не говорю, что Ruby on Rails, потому что я хочу продолжить использовать JVM и я плескался с Grails в прошлом, и это было довольно легко к погрузке и использованию.
4 ответа
Возможно. Grails использует подкласс класса ContextLoaderListener от Spring, который он настраивает в файле web.xml. Я смогу ответить более точно, если вы сообщите мне, как вы делаете это в Spring MVC.
Да. Возможно, вас даже заинтересует плагин CXF, хотя я не могу поручиться за него:
Вы должны быть в состоянии использовать их как есть. Однако, возможно, вы захотите проверить, легко ли это сделать с помощью плагина Spring Security. Я считаю, что да, но окончательный ответ вы сможете получить у Берта Беквита, автора плагина.
Да. Вы также можете использовать фабрику сессий Hibernate, чтобы делать необработанные вещи в Hibernate. GORM также может работать с несколькими источниками данных:
http://grails.org/plugin/datasources
Еще один Берт Беквит :)
Это зависит от того, что вы подразумеваете под "комбинацией Groovy и Java". Вы можете создавать проекты Grails с помощью Maven, но интеграция не совсем гладкая. Если в вашем проекте Grails есть Java и Groovy, то об этом позаботятся автоматически.
Отвечая на вопрос Божо, я использую стандартные сервисы Grails + GORM и не стал бы делать это по-другому. Обратите внимание, что если вы используете Java для сервисов и доменной модели, у вас не будет автоматической перезагрузки сервисов. Вы также потеряете преимущества выразительности и краткости, которые дает Groovy.
Если вы хотите, вы можете использовать статические типы в сервисах Grails, чтобы облегчить вашей IDE завершение кода. Она также может дать вам подсказки о свойствах и методах, которые она не распознает (что будет соответствовать ошибкам компиляции Java). При этом, даже если вы используете статические типы, Groovy не может выполнять проверку типов во время компиляции. Вы узнаете о них только во время выполнения.
Вы можете делать все эти вещи в grails. Он поддерживает все существующие Java-классы и конфигурации spring (grails построен на базе spring mvc)
Однако я бы не рекомендовал переносить все приложение на grails. Возможно, вы можете перенести только веб-слой, если у вас есть веб-разработчики, не являющиеся специалистами по java.
Сервисный слой, доступ к данным и т.д. лучше оставить на чистой Java. То есть, только ваши веб-контроллеры - компоненты, которые собирают пользовательский ввод, обрабатывают http-запросы и сессии, должны использовать grails. Все остальное - классы сервисов без статических данных и ваша доменная модель - лучше использовать Java. Это мое мнение, но у меня уже есть некоторый опыт работы с grails, и статическая типизация в сервисном слое избавит вас от многих проблем.
2) Да, вы можете использовать CXF как есть. Поверх CXF есть хороший слой под названием GroovyWS . Я использовал его только для использования служб SOAP, но, возможно, в нем есть что-то и для REST. Его действительно легко использовать. Для использования служб REST я использовал HTTP Builder
4) Да. Вы можете продолжать использовать, например, spring config для настройки источника данных или любым другим способом, который вы делаете сегодня. Использование нескольких источников данных не проблема.
5) Недавно я пробовал использовать Grails (1.2.1) с Maven. Это работает, но были некоторые проблемы с Maven и Grails, пытающимися управлять зависимостями. Документация, пожалуй, самая худшая часть. Я еще не пробовал обновиться до 1.3 из-за некоторых основных JIRA, связанных с Maven, но 1.3.2 уже не за горами, и эти проблемы теперь решены :) Также будет архетип maven 1.3.2. С нетерпением жду этого. «Развертывание и разрешение плагинов из репозиториев Maven» - одна из новых функций Grails 1.3, так что, вероятно, дела обстоят лучше. В дорожной карте 1.3.2 говорится о выпуске сегодня, но на данный момент осталось еще 8 проблем, так что я предполагаю, что завтра, выпуски Grails обычно вовремя.Если вы можете дождаться этого, вы, вероятно, избавите себя от некоторых проблем.
Если вам нужна быстрая разработка приложений, но вы не в восторге от groovy, вам стоит обратить внимание на spring-roo. Он предлагает ту же самую функциональность RAD, но строит совершенно стандартное приложение java + ORM + spring-mvc (которое не имеет фактических зависимостей (runtime или compile) от roo). Он определенно не такой зрелый, как grails, но вы можете обнаружить, что он лучше подходит для вашего существующего опыта работы со статически типизированным java-кодом и существующими ORM и т.д. Я сделал только пару небольших домашних проектов на roo, но пока что я был очень впечатлен, особенно тем, как легко настраивать сгенерированный код и перемещаться вперед-назад между написанным и сгенерированным кодом. Начальный учебник очень быстрый и весьма показательный.