SpringSource (теперь VMWare) имеет две очень похожие технологии: Grails и Spring Roo. Я использую Grails, но я вижу, что SpringSource активно работает над чем-то, что является конкурентом этой технологии, и это заставляет меня беспокоиться о будущем Grails.
Кто-нибудь знает, как эти технологии связаны, они будут объединены или один из них будет оставлен?
Кроме того, существуют ли какие-либо важные технические различия между Grails и Roo?
SpringSource Цель состоит в том, чтобы сделать это как можно быстрее и проще для людей, чтобы создавать, запускать и управлять решениями на основе Spring, У нас есть Grails и Spring Roo, потому что мы глубоко заботиться о производительности труда разработчиков и, несомненно, оба эти инструмента нанести серьезный толчок к тому, что команды могут достичь в верхней части Spring.
У нас есть обе технологии, потому что Roo и Grails очень разные на философском уровне и уровне реализации (как уже отмечалось в других ответах). Каждая технология приближается к ее основному языку (Java или Groovy) и операционной модели (dev-time или runtime) с философией "как сделать предложение ценности невероятно хорошим, используя этот язык и комбинацию операционной модели?". Таким образом, вы увидите, что каждая технология использует другой стиль, который максимизирует эту комбинацию (Roo Java + Dev-time или Grail Groovy + Runtime) и соизмеримые преимущества.
Эти различия на самом деле очень положительные, потому что они означают, что сообщество Spring может выбрать, какой "вкус" решения производительности они предпочитают. Хотя эти первоначальные различия в выборе языка и времени выполнения/времени автономной работы сразу же очевидны, выбор Grails или Roo также распространяется на более тонкие соображения, такие как используемые по умолчанию технологии, модель взаимодействия с пользователем, поддержка IDE, зависимости, стандарты, дорожная карта, расширений и т.д. Почти все эти различия являются естественным следствием достижения лучшего в своем роде решения для определенного языкового стиля.
Наш лучший совет - рассмотреть оба решения. У каждого есть свои сладкие пятна, но между ними есть различия, которые улучшат ваш общий опыт с помощью одной технологии или другой в данном контексте. Оба справочных руководства подробно описывают соответствующие преимущества каждое решение. Конечно, помните, что время инвестиций минимально в попытке обойти. Через 10 минут вы можете построить проект в Roo или Grails, поэтому попробуйте и посмотрите, что для вас более естественно, учитывая ваши конкретные предпосылки и потребности проекта.
Основное отличие состоит в том, что Roo - это чистая Java-инфраструктура, тогда как Grails использует Groovy, а также Java. Оба они построены на ядре Spring и используют популярные Java-библиотеки с открытым исходным кодом.
Этот вопрос был задан назад, когда был объявлен Roo, и Грэм Рошер (Grails lead) говорит, что обе структуры имеют место в пределах Spring и поддерживаются одинаково.
Во всяком случае, я думаю, что у Грайла есть более светлое будущее, чем у Ру. Мне нравится развиваться с ним и не вижу никаких недостатков, чтобы он не был чистой Java.
Грааля и Роо очень разные. Первым важным отличием является используемый язык. Хотя вы можете написать Groovy код, например, традиционный Java-код, для выполнения приложений Grails вам понадобятся зависимости Groovy. Чтобы быть как можно более продуктивным в Grails, вам также нужно иметь представление о функциях в Groovy, которые в настоящее время не являются частью Java, например Closures. Другое отличие - это философия, которую создают рамки для генерации кода. Grails генерирует множество методов во время выполнения, в то время как Roo генерирует их по запросу в процессе разработки. У Roo нет за кулисами магия принять за использование аспектно-ориентированного программирования, и вы можете просмотреть весь код, который генерирует Roo. Например, в Roo вы должны использовать команду для генерации динамических методов поиска, таких как findByBook(), а затем просмотреть сгенерированный код в файлах .aj. В Grails метод findByBook() создается во время выполнения, и вы не можете просмотреть сгенерированный код. Roo также позволяет вам прекратить использование фреймворка, если вы выбрали, продолжая работать с запущенным приложением, объединив весь сгенерированный код в обычные .java файлы. Тогда у вас нет зависимостей от каких-либо библиотек Roo во время выполнения или времени разработки. Если вы решите, что вам не нравится Grails, у вас нет возможности прекратить использовать фреймворк, продолжая работать с действующим приложением.
ИМО, они не очень похожи. Несмотря на сходство, следующие существенные различия:
Roo очень похож на систему командной строки Grails (например, команды типа create-app, create-domain-class, test-app, найденные в Grails). Я не удивлюсь, если увижу какое-то "перекрестное опыление" между этой частью рамки Grails и Roo.
На самом деле они не похожи. Roo делает это волшебство во время компиляции, где Grails делает это во время выполнения. Из-за этого проекты Roo не влияют на производительность во время выполнения.
Я не вижу, как они могут быть объединены, поскольку Grails построен на Groovy и Roo на Java.
Я видел некоторые комментарии к спискам рассылки Grails, которые указывали, что авторы полагали, что Roo существует только как ступенька к Grails! Однако я лично рассматриваю возможный переход от Grails к Roo. Я думаю, что основное различие между динамическими и статически типизированными языками - для меня это огромное. Мне нравятся многие функции Grails, но я предпочитаю поддержку IDE и проверку времени статического ввода текста. Некоторые другие чувствуют себя совершенно наоборот, поэтому лошади для курсов. Тем не менее, статический groovy в настоящее время находится в тяжелом развитии, поэтому кто знает, что ждет в будущем.
У нас было требование, когда у нас было приложение в производстве и было разработано в Spring MVC, а скорость разработки новых функций была медленной. Нам пришлось исследовать альтернативные рамки, такие как Grails and Roo. Я лично провел около месяца, изучая, какой из них лучше.
Если вы хотите увидеть подробности анализа, посетите @http://krishnasblog.com/2012/05/08/roo-vs-grails/
Мы рассмотрели следующие функции, как в этих, так и ниже, наши выводы. Окончательный вердикт, мы не уверены, что будем использовать один из них, мы все еще изучаем