Кенгуру Spring По сравнению с (Калитка и Spring)

В нашем текущем проекте используются Spring и Wicket, мы всегда использовали Spring, но перешли на Wicket год назад. Несколько советов:

• Получите книгу «Wicket in Action».
• Список рассылки пользователей очень полезен.
• Убедитесь, что вы понимаете модель программирования Wicket, особенно в том, что касается сериализации сеансов (книга недостаточно помогает в ИМХО).
• Wicket хорош для создания страниц с сохранением состояния, для создания страниц без состояния требуется больше работы.
• Есть несколько хороших виджетов пользовательского интерфейса, таких как inmethod DataGrid.
• Легко внедрить ваши компоненты Spring в ваши страницы или компоненты.

Spring Roo все еще находится в стадии бета-тестирования (1.0 M2), так что это может быть немного раньше. Мы также рассматривали Tapestry 5, но еще год назад нам показалось, что он немного молод.

Я был на конференции SpringOne в Амстердаме в начале этого года, когда они объявили о Roo. Мое впечатление (и мнение моего коллеги, который был там), было то, что Roo был хорош, если вы создавали веб-приложение CRUD каждые несколько недель - они представили его как чистую версию Java Grails (которая является RoR для Java).

Больше никого не интересовало - но это всего лишь мнение.

Это полностью зависит от ваших требований. Если это небольшой сайт, то компонентно-ориентированные фреймворки, такие как GWT или Wicket, обязательно , поскольку они делают вещи действительно легкими.

Spring Roo 1.0.0 (GA) уже выпущен, в нем содержится около 100 страниц документации.

Если вам интересно, что такое Roo и зачем его использовать , я рекомендую вам прочитать вводную главу справочного руководства. Он охватывает это и многое другое.

@Antony, Поддержка GWT является основным приоритетом для Roo, и я сейчас над этим работаю. Ожидайте увидеть интересную интеграцию в самом ближайшем будущем.

Я видел демонстрацию ROO несколько месяцев назад. Он выглядит очень похоже на Grails (другая пружинная технология), за исключением того, что вместо того, чтобы создавать артефакты для Groovy язык, вы создаете их для Java.
Тем не менее, это обеспечивает хорошую практику и заставляет вас применить картину MVC чистым способом.

Лично демонстрация не заставляла меня изменить мой предпочтительный инструментарий (Grails), но это потому, что я могу добиться быстрее результатов с Groovy (разбор XML, например, гораздо более «болезненно» в Java, чем в Groovy). Кроме того, с Grails я могу видеть изменения, которые я делаю мгновенно без необходимости перекомпилировать весь свой проект и отменить приложение каждый раз, когда я хочу увидеть результаты. Последнее, но не менее важное, в Grails у вас есть тонны плагинов, чтобы сделать необычные сайты Ajax (например, ZK, если вы хотите избежать JavaScript, но есть плагины для GWT, Yahoo, Dojo и т. Д.).

Итак, если вы не хотите изучать Groovy (что не слишком сложно, если вы уже знаете Java), ROO - это путь к построению чистых веб-проектов со всей силой гибернации и весной.

Я надеюсь, что это поможет ...

Как скоро с поддержкой Roo GWT? Я думаю, что использование GWT от Roo делает его огромной победой для GWT и Roo!

Во-первых, Spring Roo - это инструмент для генерации кода (похожий на Grails commands system):

_{(источник: springsource.com)}

Во-вторых, приложения Spring Roo в настоящее время используют Spring Web Flow для просмотра и Spring для клея.

Итак, хотя вы можете сравнить (Spring Web Flow + Spring) и (Wicket + Spring), более поздняя комбинация не предлагает ничего сравнимого с Roo (может быть AppFuse или AppFuse Light, но вы не упоминали о них, и они являются сторонними проектами).

Другими словами, я не думаю, что "Spring Roo vs (Wicket and Spring)" имеет смысл.

Roo и GWT доступны сегодня в предрелизной форме. На мой взгляд, они определенно не готовы к прайм-тайму.

Зачем использовать Roo, если можно построить что-то с GWT и получить гораздо более богатый лучший результат и без ограничений Roo и его архитектуры. Spring Web Flow - это вчерашняя технология.