Грааль или Играй! для бывшего разработчика RoR? - PullRequest
21 голосов
/ 27 марта 2010

Я планирую начать изучать веб-фреймворк Java (мне нравится Java API). Я уже использовал Rails и Django.

Я хочу что-то близкое к Java, но без всей сложности J2EE.

Я нашел 2 фреймворка, которые могли бы быть мне полезны:

Grails

Grails выглядит великолепно, он использует Groovy, который лучше, чем Java, для веб-приложений (я думаю ..), но он медленнее, чем фреймворки на основе чисто Java (Hibernate, Strut, Spring). Он выглядит довольно простым для развертывания (отправка .war и все нормально!) GSP отличная! Отладить его немного сложнее (необходимо перезапускать сервер при каждой модификации, а в трассировках стека содержатся сочетания трассировок Java и Groovy, что не всегда легко понять)

Играть!

Эта структура также выглядит великолепно; это быстрее, чем Grails (он использует Java), но мне не очень нравится, как он использует Java, он изменяет исходный код для преобразования вызовов свойств как setXXX / getXXX, мне это не нравится ... Фреймворк также имеет кэширование функция, которой Grails не имеет. Мне не очень нравится Template Engine. Также легче отлаживать (не нужно перезагружать сервер, следы стека понятнее)

Что вы рекомендуете? Я ищу что-то простое в освоении (у меня есть большой опыт работы с Ruby, не так уж много опыта в Java, но я люблю Java API), полнофункциональный (это не проблема со всей доступной библиотекой Java, но если она в комплекте и интегрирована Я предпочитаю), имеет хорошую масштабируемость и не слишком медленный (быстрее, чем Ruby). В идеале я хотел бы использовать инфраструктуру с приличным сообществом, чтобы легко находить поддержку.

PS: меня не интересует JRuby on Rails

Ответы [ 6 ]

29 голосов
/ 08 марта 2011

Я переключился с Grails на Play и никогда не оглядывался назад. Моя самая большая проблема с Grails - это общая надежность и удобство использования для разработчиков. Большую часть времени меня укусил тот факт, что Grails склеивает обычный стек Spring MVC и Hibernate, пытаясь скрыть этот факт и предоставляя вам подобный Rails API (мое личное мнение). Проблема в том, что когда что-то выходит за рамки тривиальных образцов, оно легко ломается и не работает для меня. Развиваться с этим было все равно что ходить по яйцам (для меня). Всякий раз, когда я гуглил документацию по нужной мне функции, меня перенаправляли не на образцы, учебные пособия, блоги, а на Grails JIRA, объясняющую, почему эта функция не работает для моего варианта использования, и что ошибка была устранена, поскольку две версии до одной Я использовал.

Хотя это может не быть общим опытом для каждого разработчика (я не пишу это для bash Grails, но для того, чтобы поделиться своим опытом с этим здесь), мне нужно что-то, что помогло бы мне и не встало бы у меня на пути или сломалось на меня, когда мне это было нужно больше всего. Вот когда я нашел Play, и я быстро перенес свое приложение в него после того, как узнал об этом (примерно в версии 1.0).

Пока это была отличная поездка, и впервые в моей карьере веб-разработчика я перестал смотреть на другие фреймворки, пытаясь найти что-то, что мне бы хотелось больше.

Если бы мне пришлось закончить с одной вещью, что Play лучше, чем Grails - по крайней мере, для меня - это был бы тот факт, что Play создан с нуля с учетом удобства использования для разработчиков. Это не жертвует простотой использования для модных словечек предприятия. У него хватит смелости выбросить то, что не вписывается в эту парадигму (например, отказ от времени выполнения на основе сервлетов во время разработки для более быстрого выполнения). Он готов идти на компромиссы, чтобы гарантировать удивительность. И это то, что я видел только в таких сообществах, как Rails или Django, до того, как нашел Play.

23 голосов
/ 27 марта 2010

Я бы предложил Grails. Он имеет большее сообщество, чем игровая среда (~ 350 плагинов, покрывающих практически все основные потребности). Кроме того, Grails написан почти полностью на Java, он просто позволяет вам использовать Groovy для конкретной реализации вашего домена.

Если вы столкнулись с проблемой производительности, когда созданные вами нестандартные страницы являются узким местом, вы всегда можете просто переключиться на реализацию Java. Тогда вы окажетесь в той же лодке, в которой были бы все время с платформой Play. Вы оптимизировали время разработки, отложив кодирование вещей на Java, пока не узнаете, что вам действительно нужно это делать (что, по моему опыту, очень редко).

Я также не уверен, откуда вы узнали, что вам нужно перезапускать сервер для каждой модификации, но на самом деле это не так. Grails поддерживает перезагрузку объектов контроллеров / gsps / services / domain и т. Д. Без перезагрузки сервера.

Смешанные трассировки стека могут быть немного длиннее, но производители инструментов (такие как Intellij) внесли некоторые недавние улучшения, которые убирают все части трассировки стека, которые вам не нужны.

Я использую Grails с .5 дней и очень доволен платформой.

3 голосов
/ 05 декабря 2011

Из моего опыта с Play это отличная структура.Мои любимые функции - это крутая система контроллеров и система шаблонов - и то, и другое простое, но многофункциональное и мощное.

Однако наиболее важным преимуществом Play, безусловно, является быстрый цикл разработки, при котором перезагрузка практически не требуетсяизменения кода.Но если вы не будете осторожны, это величие не будет длиться долго, и в конечном итоге медлительность проникнет в ваш код.

Почему это так?В Play часто используются некоторые плагины с довольно сложной инициализацией, в частности EJB (Hibernate) и Spring.Инициализация этих плагинов перезапускается при каждом изменении кода перед загрузкой нового кода.В результате этого, по мере роста вашей модели и конфигурации вашей системы, эта тяжелая инициализация начинает серьезно замедлять вашу разработку.В системе, которую я использовал, 20 секунд были обычным временем запуска на виртуальной машине, работающей на отличном ноутбуке.

Что вы можете сделать, чтобы избежать этого, зависит от вашего приложения, например, если вы создаете приложение NoSQL, тотогда плагин EJB не должен доставлять вам хлопот.Spring можно заменить собственным жестко запрограммированным Java-плагином, который также проще поддерживать в IMHO, или запустить скрипт Groovy, если скриптовость так важна.В любом случае, следите за этими проблемами и убивайте их, пока вы молоды, и убедитесь, что вы не будете запускать собственные громоздкие инициализации при каждом обновлении.

3 голосов
/ 15 ноября 2010
1 голос
/ 27 марта 2010

Если вы раньше использовали Ruby и Python, вам, вероятно, понравится Grails лучше, чем Play. Когда вы привыкли к этим динамическим языкам, очень трудно вернуться к Java.

0 голосов
/ 27 марта 2010

Есть также Лифт на Скала .
Imho scala - лучший статический типизированный язык, а lift - довольно приятная среда (для статического типизированного языка).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...