Grails по сравнению с Кенгуру - почему SpringSource продвигает две очень похожих технологии?
SpringSource (теперь VMware) имеет две очень похожих технологии: Grails и Кенгуру Spring. Я использовал Grails, но я вижу, что SpringSource активно работает над чем-то, что является конкурентом для той технологии, и это делает меня взволнованным по поводу будущего Grails.
Кто-либо знает, как эти технологии имеют отношение, будут, они объединились, или от одного из них откажутся?
Кроме того, есть ли какие-либо важные технические различия betweent Grails и Кенгуру?
7 ответов
][]SpringSource[] стремится к тому, чтобы люди могли как можно быстрее и проще создавать, запускать и управлять решениями, основанными на Spring. У нас есть как [] Grails [], так и [] Spring Roo [], потому что мы глубоко заботимся о производительности разработчиков и, несомненно, оба этих инструмента дают серьезный толчок тому, чего команды могут достичь на вершине весны.[
] [] У нас есть обе технологии, потому что Roo и Grails очень сильно отличаются на философском уровне и уровне реализации (как уже отмечалось в других ответах). Каждая технология приближается к своему основному языку (Java или Groovy) и операционной модели (devtime или runtime) с философией "как сделать ценностное предложение невероятно хорошим, используя эту комбинацию языка и операционной модели". Таким образом, вы увидите, что каждая технология принимает свой стиль, который максимизирует эту комбинацию (Roo Java+Dev-time или Grail's Groovy+Runtime) и соизмеримые преимущества. [
] [] Эти различия на самом деле очень положительные, потому что они означают, что сообщество Spring может выбрать, какой "вкус" решения производительности они предпочитают. В то время как эти первоначальные различия, связанные с выбором языка и работой в режиме runtime/devtime, очевидны немедленно, выбор Grails или Roo также распространяется на более тонкие соображения, такие как используемые по умолчанию технологии, модель взаимодействия с пользователем, поддержка IDE, зависимости, стандарты, дорожная карта, расширения и т.д. Почти все эти различия являются естественным следствием поиска лучшего в своем роде решения для определенного стиля языка.[
] []Наш лучший совет - рассмотреть оба решения. Каждое из них имеет свои "сладкие места", но есть различия между ними, которые сделают ваш общий опыт лучше с одной технологией или с другой в данном контексте. В обоих справочных руководствах подробно описаны соответствующие преимущества [] [] [] каждого решения []. Конечно, помните, что время, затрачиваемое на опробование обоих решений, минимально. За 10 минут вы можете построить проект в Ру или Граале, так что попробуйте и посмотрите, что кажется более естественным для вас, учитывая вашу конкретную историю и потребности проекта.[
].На самом деле они не так уж и похожи. Roo делает это волшебством во время компиляции, где Грааль делает это во время выполнения. Поэтому проекты Roo не берут никаких хитов производительности во время компиляции.
Я не понимаю, как они могут быть объединены, так как Грааль построен на Groovy и Roo на Java.
ИМО не очень похожи. Несмотря на сходство, существуют значительные различия:
- Roo использует "Stock-Standard Java", Грааль основан на Groovy
- Grails - это Web-фреймворк, Roo не
Roo очень похожа на систему командной строки Грааля (например, команды типа -приложение к созданию , -класс создания-домена , -приложение к тесту , найденные в Граалях). Я не удивлюсь, если увижу некоторое "перекрестное опыление" между этой частью фреймворка Граалей и Roo.
Главное отличие состоит в том, что Roo является чистым Java-фреймворком, в то время как Grails использует Groovy, а также Java. Оба они построены на основе базовых библиотек Spring и используют популярные библиотеки Java с открытым исходным кодом.
Этот вопрос был задан еще когда было объявлено о Roo, и Graeme Rocher (ведущий Grails) говорит, что оба фреймворка имеют место в пределах весны и поддерживаются одинаково.
Если что, то я думаю, что у Граалей есть более светлое будущее, чем у Ру. Мне нравится разрабатывать с ним и я не вижу никаких недостатков в том, что он не является чистой Java.
Бен Алекс из SpringSource рассказывает о Ру в этом интервью , и его спрашивают о Grails vs Roo. Основное отличие, помимо использования разных языков (Groovy против Java, как упоминалось другими), заключается в том, что Roo в основном является инструментом времени разработки, а Grails больше участвует во время выполнения.
Граальс и ROO очень разные. Первое серьезное различие - это используемый язык. Хотя вы можете написать Groovy Code, как традиционный код Java, вам все равно нуждаются в Groovy-зависимости, чтобы запустить приложения Grails. Чтобы быть максимально продуктивным, насколько это возможно в Grails, вам также нужно понять особенности в Groovy, которые в настоящее время не являются частью Java, таких как закрытие. Еще одна разница - это философия, которые рамоты принимают к созданию кода. Grails генерирует много способов во время выполнения, а ROO генерирует их по запросу во время процесса разработки. ROO не имеет позади сцен Magic, принимает для использования аспектно-ориентированного программирования, и вы можете просмотреть весь код, который генерирует ROO. Например, в ROO вы должны использовать команду, чтобы она генерировала динамические методы искателя, такие как findbybook (), а затем просмотр сгенерированного кода в файлах .aj. В Grails метод FindbyBook () создан во время выполнения, и вы не можете просматривать сгенерированный код. ROO также позволяет вам прекратить использовать фреймворки, если вы решили, продолжая выполнять запускное приложение, объединяя весь генерированный код в обычные файлы .java. Затем у вас нет зависимостей в любых библиотеках ROO при любом времени выполнения, ни время проекта. Если вы решите, что вам не нравится Grails, нет способа перестать использовать рамки, продолжая иметь функционирующее приложение.
Я видел некоторые комментарии в списках рассылки Grails, которые указывали на то, что авторы считают, что Roo существует только как ступенька к Grails! Однако я лично рассматриваю возможность перехода с Grails на Roo. Я думаю, что основная разница между динамическими и статически типизированными языками - для меня это огромная разница. Мне нравятся многие функции Grails, но я предпочитаю поддержку IDE и проверку статически типизированного языка во время компиляции. Некоторые считают прямо противоположным, отсюда лошади для курсов. Тем не менее, static groovy в настоящее время интенсивно разрабатывается, так что кто знает, что нас ждет в будущем.