Учитывая переход от Java/Spring MVC к Grails

В настоящее время я использую Java и Spring (MVC) для создания webapp, и я подумываю о переходе на Grails. Я был бы признателен за отзывы и понимание:

  • У меня есть несколько контекстов приложения в текущем Java/ Spring webapp, который я загружаю через web.xml ContextLoaderListener; возможно ли иметь множество приложений в Grails? Если, да, как?

  • В этом веб-приложении широко используется веб-служба CXF, и текущий Java/ Spring webapp использует связанный клиент HTTP CXF. Могу ли я продолжать использовать (Java) CXF HTTP Client в Grails?

  • Я реализовал Spring Безопасность с использованием пользовательской реализации UserDetails и UserDetailsService, могу ли я повторно использовать эти реализации в Grails "как есть" или должен ли я их повторно реализовать?

  • Есть экземпляр, где я использовал шаблон Spring jdbc (а не доступный ORM) и дополнительный источник данных, который я определил в контексте приложения, могу ли я повторно использовать это в Grails?

  • Я планирую использовать Maven как инструмент управления проектами; есть ли проблемы с использованием Maven с Grails, где есть комбинация groovy и java?

Edit: Я рассматриваю возможность перехода на Grails, чтобы сделать разработку веб-компонента webapp "быстрее", a la Ruby-on-Rails. Кроме того, я рассматриваю Grails вместо того, чтобы говорить Ruby-on-Rails, потому что я хочу продолжать использовать JVM, и в прошлом я играл с Grails, и было довольно легко подобрать и использовать.

ОТВЕТЫ

Ответ 1

  • Возможно. Grails использует подкласс класса Spring ContextLoaderListener, который он настраивает в файле web.xml. Я могу ответить более точно, если вы сообщите мне, как вы это делаете с помощью Spring MVC.

  • Да. Вас может даже интересовать плагин CXF, хотя я не могу ручаться за него:

    http://grails.org/plugin/cxf

  • Вы должны иметь возможность использовать их как есть. Однако вы можете проверить, легко ли это сделать с помощью плагина Spring Security. Я считаю, что это так, но вы сможете получить окончательный ответ от Берт Беквит, автора плагина.

  • Да. Вы также можете получить сеанс Hibernate factory, чтобы сделать материал Hibernate. GORM также может работать с несколькими источниками данных:

    http://grails.org/plugin/datasources

    Другой Берт Беквит один:)

  • Это зависит от того, что вы подразумеваете под "комбинацией Groovy и Java". Вы можете создавать проекты Grails с Maven, но интеграция не является полностью гладкой. Если у вас есть Java и Groovy в вашем проекте Grails, то об этом заботятся автоматически.

В ответ на Bozho я использую стандартные сервисы Grails + GORM и не буду делать это иначе. Обратите внимание: если вы используете Java для служб и модель домена, у вас не будет автоматической перезагрузки служб. Вы также теряете преимущества выразительности и лаконичности, которые приносит Groovy.

Если вы хотите, вы можете использовать статические типы в службах Grails, чтобы упростить для вашей среды IDE завершение кода. Он также может дать вам подсказки о свойствах и методах, которые он не распознает (что соответствовало ошибкам компиляции Java). Тем не менее, даже если вы используете статические типы, Groovy не может выполнять проверки типа во время компиляции. Вы узнаете о них только во время выполнения.

Ответ 2

Вы можете все это сделать в граале. Он поддерживает все существующие Java-классы и spring конфигурации (grails построен ontop spring mvc)

Однако я бы не рекомендовал переместить все приложение в grails. Вы можете перемещать только веб-слой, если у вас есть веб-разработчики, которые не являются экспертами java.

Уровень обслуживания, доступ к данным и т.д., лучше остаются чистой Java. То есть, только ваши веб-контроллеры - компоненты, которые собирают ввод пользователя, обрабатывают HTTP-запросы и сеансы, должны использовать grails. Остальное - классы обслуживания без учета состояния и ваша модель домена будут лучше Java. Это мое мнение, но у меня уже есть некоторый опыт работы с grails, а статическая типизация на уровне сервиса сэкономит вам много неприятностей.

Ответ 3

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 не за горами, и эти проблемы теперь решены:) Там также будет архетип 1.3.2 maven. Ждем этого. "Развертывание и разрешение плагинов из репозиториев Maven" является одной из новых возможностей Grails 1.3, поэтому, наверное, лучше. "Дорожная карта" для версии 1.3.2 говорит о выпуске сегодня, но во время выступления осталось 8 вопросов, поэтому, как я предполагаю, завтра, выпуски Grails, как правило, вовремя. Если вы можете дождаться этого, вы, вероятно, сбережете себе некоторые проблемы.

Ответ 4

Если вы ищете быструю разработку приложений, но особо не в восторге от groovy, вы должны изучить spring -roo. Он предлагает такую ​​же функциональность RAD, но создает полностью стандартное приложение Java + ORM + spring -mvc (у которого нет реальных зависимостей (время выполнения или компиляция) на roo). Он определенно не настолько зрелый, как grails, но вы можете обнаружить, что он лучше подходит вашему существующему опыту со статически типизированным кодом Java и существующим ORM и т.д. Я только сделал несколько небольших домашних проектов в роу, но я был очень до сих пор впечатлен, особенно с тем, насколько легко настраивать сгенерированный код и перемещаться вперед и назад между написанным и сгенерированным кодом. Начальный учебник очень быстрый и довольно показательный.