Grails vs Roo - почему SpringSource продвигает две очень похожие технологии?

Question

SpringSource (сейчас VMWare) имеет две очень похожие технологии: Grails и Spring Roo. Я использовал Grails, но я вижу, что SpringSource активно работает над тем, что является конкурентом этой технологии, и это заставляет меня беспокоиться о будущем Grails.

Кто-нибудь знает, как эти технологии связаны, будут ли они объединены, или одна из них будет заброшена?

Кроме того, есть ли важные технические различия между Grails и Roo?

Answer 1

SpringSource Цель состоит в том, чтобы сделать как можно быстрее и проще для людей создание, запуск и управление решениями на основе Spring. У нас есть и Grails и Spring Roo , потому что мы глубоко заботимся о производительности разработчиков, и, несомненно, оба эти инструмента обеспечивают серьезное повышение того, что команды могут достичь в Spring.

У нас есть обе технологии, потому что Roo и Grails сильно отличаются друг от друга на философском уровне и на уровне реализации (как уже отмечалось в других ответах). Каждая технология приближается к своему основному языку (Java или Groovy) и операционной модели (время разработки или время выполнения) с философией «как сделать предложение ценности невероятно хорошим, используя эту комбинацию языка и операционной модели?». Таким образом, вы увидите, что каждая технология принимает свой стиль, который максимизирует эту комбинацию (Java + Dev-time Roo или Groovy + Runtime Grail) и соответствующие преимущества.

Эти различия на самом деле очень положительные, потому что они означают, что сообщество Spring может выбрать, какой «вкус» решения для производительности они предпочитают. Хотя эти первоначальные различия между выбором языка и работой во время выполнения / временем разработки очевидны, выбор Grails или Roo также распространяется на более тонкие соображения, такие как используемые по умолчанию технологии, модель взаимодействия с пользователем, поддержка IDE, зависимости, стандарты, план действий, расширения и т. д. Почти все эти различия являются естественным следствием поиска лучшего в своем классе решения для определенного стиля языка.

Наш лучший совет - рассмотреть оба решения. У каждого есть свои плюсы, но между ними есть различия, которые улучшат ваш общий опыт с одной или другой технологией в заданном контексте. В обоих справочных руководствах подробно описаны соответствующие преимущества каждого решения . Конечно, помните, что время, затрачиваемое на испытание обоих, минимально. Через 10 минут вы можете построить проект в Roo или Grails, так что попробуйте и посмотрите, что для вас более естественно, учитывая ваш конкретный опыт и потребности проекта.

Answer 2

Основным отличием является то, что Roo - это чистый Java-фреймворк, тогда как Grails использует Groovy и Java. Оба построены на основных библиотеках Spring и используют популярные библиотеки Java с открытым исходным кодом.

Этот вопрос был задан еще тогда, когда было объявлено Roo, и Грэм Роше (руководитель Grails) сказал, что обе среды имеют место в Spring и поддерживаются одинаково.

Если что, я думаю, у Граилса светлое будущее, чем у Ру. Я люблю разрабатывать с ним и не вижу никаких недостатков в том, что он не является чистой Java.

Answer 3

Грааль и Ру очень разные. Первым основным отличием является используемый язык. В то время как вы можете писать код на Groovy, как на традиционном Java-коде, вам все же нужны зависимости Groovy для запуска приложений Grails. Чтобы быть максимально продуктивным в Grails, вам также необходимо иметь представление о возможностях Groovy, которые в настоящее время не являются частью Java, таких как Closures. Другое отличие заключается в философии, которую используют фреймворки для генерации кода. Grails генерирует множество методов во время выполнения, в то время как Roo генерирует их по запросу в процессе разработки. У Roo нет закулисной магии для использования аспектно-ориентированного программирования, и вы можете просмотреть весь код, который генерирует Roo. Например, в Roo вы должны использовать команду, чтобы она генерировала методы динамического поиска, такие как findByBook (), а затем просматривала сгенерированный код в файлах .aj. В Grails метод findByBook () создается во время выполнения, и вы не можете просматривать сгенерированный код. Roo также позволяет вам прекратить использование фреймворка, если вы решили, продолжая иметь запущенное приложение, объединяя весь сгенерированный код в обычные файлы .java. Тогда у вас не будет никаких зависимостей ни от каких библиотек Roo ни во время выполнения, ни во время разработки. Если вы решите, что вам не нравятся Grails, вы не сможете прекратить использование платформы, продолжая иметь работающее приложение.

Answer 4

ИМО оба не очень похожи. Несмотря на то, что есть сходства, следующие существенные различия:

• Roo использует "Stock-Standard Java", Граальс основан на Groovy
• Grails - это веб-фреймворк, а Roo - не

Roo очень похож на систему командной строки Grails (например, команды типа create-app, create-domain-class, test-app, найденные в Grails). Я не удивлюсь, увидев некоторое «перекрестное опыление» между этой частью структуры Grails и Roo.

Answer 5

Бен Алекс из SpringSource рассказывает о Ру в этом интервью , и его спрашивают о Граилсе против Ру. Основное отличие от использования разных языков (Groovy и Java, как уже упоминалось) заключается в том, что Roo - это, в основном, инструмент времени разработки, а Grails больше вовлечен во время выполнения.

Answer 6

Я видел некоторые комментарии в списках рассылки Grails, в которых указывалось, что авторы считают, что Roo существует только как ступенька к Grails! Однако я лично рассматриваю возможность перехода с Grails на Roo. Я думаю, что главное различие между динамическими и статически типизированными языками - для меня это огромно. Мне нравятся многие функции Grails, но я предпочитаю поддержку IDE и проверку во время компиляции статически типизированного языка. Некоторые другие чувствуют себя с точностью до наоборот, поэтому лошади для курсов. Тем не менее, static groovy в настоящее время находится в стадии разработки, поэтому кто знает, что ждет в будущем.

Answer 7

Они на самом деле не так похожи. Roo делает это волшебно во время компиляции, где Grails делает это во время выполнения. Из-за этого проекты Roo не получают никаких потерь производительности во время выполнения.

Я не понимаю, как их можно объединить, поскольку Grails построен на Groovy и Roo на Java.

Answer 8

У нас было требование, когда у нас было приложение в производстве, и оно было разработано в Spring MVC, и скорость разработки новых функций была низкой. Нам пришлось исследовать альтернативные фреймворки, такие как Grails и Roo. Лично я провел почти месяц, изучая, какой из них был лучше.

Если вы хотите увидеть подробности анализа, посетите @ http://krishnasblog.com/2012/05/08/roo-vs-grails/

Мы исследовали следующие особенности, как в этих, так и в следующих наших выводах. Окончательный вердикт, мы не уверены, что будем использовать какой-либо из них, мы все еще изучаем