Стоит ли Grails (сейчас)?

Question

Я знаю, что это дубликат , однако мир Grails значительно изменился с тех пор, как этот вопрос был задан более года назад, как и поддержка IDE в Eclipse, поэтому, пожалуйста, не просто закрой это вслепую.

Я думал, что ответ был да, и приступил к новому проекту с Grails 1.2.0 и заигрывал с битами Groovy / Grails STS Eclipse Integration .

Я думаю, что этот вопрос заслуживает повторного рассмотрения после года эволюции Грааля, когда ответ был определенно смешанным.

Итак, как опытный веб-разработчик на Java, у меня есть следующие вопросы, и я был бы рад моим предположениям оспаривание:

• Стоит ли теперь Grails против Руби или бросить свой собственный?
• Преодолел ли он свое глючное начало?
• Действительно ли это дает преимущества быстрой разработки? (Я признаю, что сейчас изо всех сил пытаюсь преодолеть обширную базовую конфигурацию, чтобы сделать свое приложение, не ориентированное на списки и страницы)
• Работает ли он для реальных производственных приложений? (кажется тяжелым)
• Является ли плагин Eclipse лучше, чем он был, и подходит для этой цели? (думаю пока нет)

Спасибо

EDIT: Я учусь по ходу дела, и у меня есть пара существенных проблем, связанных с жизнью с фреймворком, а не сами возможности фреймворка. Я добавляю их, потому что я думаю, что они должны быть соображениями и основаны на моем опыте и мнении, и могут помочь кому-то, кто пытается решить, идти ли Граалсу. Возможно, я также показываю, что у меня нет опыта работы с фреймворком, поэтому ни одна из них не подразумевает откровенную критику. Я опытный разработчик, и вот что я нашел:

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

Регистрация откровенно ужасна . У вас есть два режима: «ничего полезного» и «чрезмерное количество бесполезных вещей». Мой журнал отладки был 128Mb после одностраничного запроса и ничего не содержит о моей ошибке. На мой взгляд, весь вопрос ведения журналов требует пересмотра в рамках.

Среда IDE STS Eclipse имеет предельное значение . Кроме подсветки синтаксиса это не очень полезно. Вы не можете отлаживать код, так что это прославленный редактор. Подсказки кода неоднозначны, и, насколько я вижу, поддержки GSP вообще нет. Это также самый медленный плагин Eclipse, который у меня есть на рабочем столе - примерно за 2 минуты до запуска. Это невероятно медленно. Я вернулся к текстовому редактору (который вы заметите и во всех обучающих видео онлайн) и к некоторому изменению синтаксиса.

У меня есть серьезные опасения по поводу производительности . Слишком рано говорить, но я уже нахожусь в процессе настройки базы данных из-за спящего режима. Возможно, этого и следовало ожидать, но мне действительно нужно, чтобы моя модель предметной области была простой, чтобы соглашения давали производительные запросы.

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

Answer 1

Я использую Grails уже более 4 месяцев, и я постараюсь дать вам мое личное представление о Grails и его удобстве использования.

Стоит ли теперь Grails против Ruby или другого собственного ролла?

Конечно, ответ не "Да" или "Нет", но это зависит . Это зависит от ваших требований (вам нужно быть в Java World?), А также от ваших предпочтений (вы предпочитаете доменно-ориентированную разработку, вы предпочитаете Groovy ...)? Однако я могу ответить, что Grails - это серьезная альтернатива Rails. Я считаю, что независимо от того, какое у вас приложение на Rails, вы можете сделать это и с Grails. Но в зависимости от характера вашего проекта, это может занять больше или меньше времени. Опять же, если вы знакомы с Rails, но не знакомы с Grails, Rails - более безопасный вариант.

Преодолел ли он свое глючное начало?

Да . Если вы посмотрите на мои первоначальные сообщения (на этом или других сайтах), я много жаловался на ошибки Grails. Но вам просто нужно помнить, что Grails немного грубоват (например, не слишком много использует наследование доменов), и как только вы познакомитесь с фреймворком, у вас не будет слишком много неприятных сюрпризов. Я не говорю, что Grails не глючит. Это, конечно, больше, чем Rails. Но также, он более полезен, чем глючит . Совет для этого: используйте как можно меньше плагинов . Потому что многие из них глючат, а некоторые не совместимы между собой. Поэтому не включайте плагин Grails, если вы не уверены, что плагин Grails является современным, ненавязчивым и проверенным (самостоятельно).

Действительно ли это дает преимущества быстрой разработки?

Да . Вам почти не нужно заниматься дизайном БД. Конфигурация почти готова для вас с самого начала, благодаря соглашению о конфигурации. Ваше приложение легко обслуживается. Единственный недостаток, который я вижу, - это интерфейсная разработка, которая не так богата, как другие технологии (например, Rails или ASP)

Работает ли он для реальных производственных приложений?

Не могу сказать, потому что я все еще не запускал свой веб-сайт, но я довольно уверен, так как sky.com использует Grails и сайты привлекают значительный трафик - 7 миллионов просмотров страниц в день . Опять же, производительность во многом зависит от архитектуры вашего приложения и проектных решений.

Является ли плагин Eclipse лучше, чем он был и подходит для этой цели?

Понятия не имею. Я использую IntelliJ, но я думаю, что это не намного лучше, чем год назад, согласно жалобным сообщениям, которые я вижу в области Grails.

Надеюсь, это поможет.

Answer 2

Недавно начал проект Rails, делал кое-что с Grails.

Моя главная особенность Rails в том, что есть много вещей, которые полностью непрозрачны для разработчика (что я ненавижу), и это имеет тенденцию увеличиваться, когда вы начинаете добавлять больше плагинов / generators / libs / etc, потому что для их объединения вам нужно что-то исправить. Вы чувствуете, что rails + plugins - это просто гигантский взлом DSL, который начинает разрушаться, если вы используете неправильную комбинацию plugins + version .

С Grails , хотя экосистема намного меньше, все имеет тенденцию быть относительно последовательным. Подход DSL используется не очень широко, и, используя обычный, но скучный дизайн (я имею в виду использование классов, интерфейсов и т. Д. Вместо DSL), гораздо проще понять, как работает сантехника.

Делая сравнение 1 к 1, вот как это происходит:

• Языковая реализация : Я предпочитаю Ruby вместо Groovy, хотя я не очень хорошо знаю Ruby. Groovy ощущается как язык с хорошим намерением и плохой реализацией, где некоторые функции добавлены к синтаксису. Я имею в виду некоторые специальные классы, которые, кажется, существуют только для того, чтобы позволить взломать.
• Особенности фреймворка : Rails далеко впереди в этом. Вы можете сконфигурировать большинство аспектов Rails (например, макеты, шаблоны, упаковщики css / js, валидацию, инфраструктуры тестирования и т. Д.) Несколькими способами. Grails отстает от этого, хотя он достаточно гибок для большинства случаев использования.
• Плагины : в Rails есть тонна плагинов, которые можно рассматривать как благословение или кошмар. Некоторые плагины не поддерживаются, другие не очень хорошо работают с некоторыми функциями или плагинами, и есть много вилок. Я учусь придерживаться основных и наиболее используемых плагинов (authlogic, haml и т. Д.) У Grails есть отличные плагины для основ (авторизация / аутентификация, ORM и т. Д.) И некоторые другие плагины для мелочей
• Тестирование : у Rails есть масса способов тестирования, но это не обязательно хорошо. Некоторые платформы тестирования не очень хорошо работают с некоторыми плагинами и т. Д. Grails имеет меньше тестовых плагинов, но, опять же, они лучше интегрируются с некоторыми из основных плагинов (потому что не так много плагинов для интеграции)
• База данных : Grails выигрывает на сегодняшний день .
  • Я предпочитаю моделировать классы своего домена, а не взламывать мою БД.
  • Hibernate (который используется под капотом) находится на расстоянии лет от своего аналога Rails. Хотя для Rails есть datamapper (который больше похож на Hibernate, чем ActiveRecord), я чувствую, что он недостаточно зрел. Grails также имеет миграции через плагин.
  • У вас есть отличные импликации кеша для Hibernate (кеш JBoss, EhCache и т. Д.), Которые могут значительно повысить вашу производительность
• Библиотеки : Я чувствую, что у Ruby есть много библиотек для новых вещей, таких как NoSQL или облачные сервисы, в то время как у Java есть множество библиотек для более старых вещей, таких как обработка Excel. Не забывайте, что библиотеки Java обычно намного быстрее, чем Ruby
• Передний край : Rails более шумиха, что означает, что за ним стоит больше ресурсов. Это означает, что если вы пытаетесь интегрировать MongoDB или Riak с Rails, есть хорошее изменение, что кто-то уже сделал это. Grails отстает, главным образом потому, что он не так популярен, поэтому сообщество стремится сосредоточиться на решении повседневных проблем, а не на использовании самых передовых технологий, таких как NoSQL и т. Д.

Вот пример:

• Большинство плагинов Grails генерируют код в виде моделей и / или сервисов. Остальное обычно обрабатывается библиотекой. Вы можете проверить код модели / сервиса, посмотреть, что он делает, и изменить его.
• Большинство плагинов Rails обычно подключаются к Rails API, что означает, что вы в конечном итоге вызываете какую-то функцию или включаете какой-то модуль, а затем используете собственный DSL плагина. Это прекрасно работает , когда работает , но когда оно ломается, это ужасно, и вам в конечном итоге приходится исправлять некоторые вещи или устанавливать другой плагин или версию плагина. Я предполагаю, что более опытный разработчик Rails будет более доволен этим, но это не так.

---

Вывод:

• Если вы хотите получить преимущество, не возражайте против случайных исправлений, отдайте предпочтение большому сообществу и / или не возражаете против использования базы данных в стиле ActiveRecord, используйте Rails . Кроме того, Ruby как язык очень элегантен
• Если вы предпочитаете дизайн интерфейса класса вместо DSL, предпочитаете моделировать свое приложение с помощью моделей, не нуждаетесь в изысканных функциях и знакомы с экосистемой Java, используйте Grails

Answer 3

Оно того стоит!

Мы используем Grails в нескольких проектах, и все они с большим успехом по следующим причинам:

• Easy - это одна из самых простых платформ, которые мы когда-либо использовали

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

• Устаревшая структура базы данных - это замечательный инструмент, если вы хотите создавать визуализации данных в унаследованных базах данных.

Теперь о жизнеспособности:

• Ошибки: с версии 1.1 мы не сталкивались с большим количеством ошибок (версия 1.0 была СЛИШКОМ глючной для нас)

• Инструменты: Netbeans действительно улучшается в этом направлении, но он даже не закрывает другие инструменты, такие как Intellij IDEA (отличная поддержка!). То же самое можно сказать об Затмении.

• Переносимость: мы никогда не сталкивались ни с одной проблемой в наших проектах.

Answer 4

Сейчас у нас в работе полдюжины приложений Grails, и хотя Grails отличается от java-фреймворков и требует некоторого времени на обучение, оно окупилось, потому что мы использовали Agile-методики. Подробности:

• Мы используем IntelliJ. Он не очень дорогой и окупился за несколько недель.
• Автоматическое тестирование, непрерывная интеграция и рефакторинг являются обязательными, как и для всего динамического языкового кода. Если вы уже практикуете TDD или, по крайней мере, имеете приличное покрытие тестовым кодом, то это не добавляет никакой дополнительной работы.
• Hibernate поставляется по умолчанию с Grails, но вы можете использовать другие персистентные фреймворки. Есть 5 других постоянных плагинов, доступных сегодня
• Ведение лесозаготовок явно не беспокоило Грэма Роше, но оно неуклонно улучшалось. Однако я не сталкивался с проблемой, когда ошибка не регистрировалась (необходимо убедиться, что вы правильно улавливаете исключения в своем коде)
• Отладка была явно не на радаре (но это не улучшилось). Мы все равно не полагаемся на отладку.

При этом, как и во всех новых технологиях, я рекомендую создавать прототипы, обзоры кода, парное программирование и, возможно, также использовать некоторые консультации.

Answer 5

Это очень того стоит. Я использую это больше года и люблю это. Раньше я уклонялся от этих типов рад-инструментов, но это изменило мою работу. С выпуском 1.2 он стал еще лучше с улучшенной информацией трассировки стека (особенно для GSP).

Единственная проблема, с которой я столкнулся при масштабировании - это спящий режим и его кеш, который на самом деле не является проблемой Grails. Даже те, кто мне не нравится в спящем режиме в целом, то, как Grails оборачивает их GORM, для меня - произведение искусства. С аспектом закрытия критериев приятно работать.

Answer 6

Мне еще предстоит найти человека, который является экспертом в Grails и Rails и предпочитает Grails.

Если вы хорошо знаете оба, то вы почти наверняка предпочитаете Rails.

Grails обычно привлекает разработчиков Java, которые боятся смены платформы.

В этом случае, я думаю, JRuby, вероятно, является лучшим способом применения гибкого подхода к устаревшему jvm.

Answer 7

Недавно воспользовавшись Grails для проекта, я хочу поделиться своим опытом по сравнению со стандартной разработкой приложений J2EE.

Действительно ли это дает преимущества быстрой разработки?

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

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

Переключение с Java на Groovy - это большое удовольствие, нам нравилось иметь список и отображать литералы, замыкания, компоновщики, чтобы отбросить нашу реализацию "map" в шаблонной таблице на Java и написать компактный, содержательный и целенаправленный код. *

Что замедляет скорость разработки, так это не столь совершенная поддержка IDE, которая также применима и к плагину IntelliJ, который мы используем. Плохая, часто старая и даже неправильная документация, разбросанная по разным местам (срывая обещание «поиск окончен»), также мешает быстрой разработке. Поэтому нам часто приходилось прибегать к чтению исходного кода, что впоследствии пугало основную иерархию классов Spring.

Answer 8

Отладка действительно сложная. Я никогда не считал это большой проблемой. Вы можете либо присоединить отладчик и пройтись по нему, либо вставить в код нагрузку println / logs, чтобы выяснить, что происходит.

Ведение журнала откровенно ужасно. Я согласен, что трассировки стеков обычно предоставляют 4 страницы бесполезной информации, иногда с информативной строкой. Однако за такую ​​потрясающую платформу стоит заплатить небольшую цену.

Среда IDE STS Eclipse имеет предельное значение. «Затмение» плохо поддерживает Грааля. Используйте IntelliJ, если это возможно. Я тупица, но если бы моя компания позволила мне, я с радостью заплатил бы за IntelliJ.

Answer 9

Я использую Grails с самых первых дней бета-версии 1.0, и я могу только рекомендовать вам начать серьезно относиться к Groovy / Grails, если вы пришли из магазина Java.

Если вы являетесь магазином Java и рассматриваете Ruby Rails, остановитесь - иди в Grails. Если Grails не работает для вас, вы всегда можете запустить Rails.

Answer 10

Я поделюсь своим 3-летним опытом использования Grails почти в десяти приложениях. Я не могу сравнить с Ruby on Rails, поэтому отвечу на другие ваши вопросы.

Преодолел ли он свое глючное начало?

• Да, это так. Я испытал несколько ошибок Grails на Grails 2.0.4 / 2.2.4.

Действительно ли это дает преимущества быстрой разработки?

• Довольно просто учиться, легко разрабатывать, никогда не видел, чтобы кто-то, хорошо знающий мир Java, потратил больше недели на изучение основ. Также прост в обслуживании. И вам не нужно много беспокоиться о вашей БД - просто убедитесь, что вы mak

Является ли плагин Eclipse лучше, чем он был и подходит для этой цели?

• Тщательно выбирайте свою IDE. Затмение мне очень помогло, но оно дает сбой и вызывает больше проблем, чем должно. Я пошел на IntelliJ, и в пробный месяц это казалось лучшим выбором. В последнее время я использую Sublime Text, несколько плагинов и старую командную строку. Я обращаюсь к IDE только в особых ситуациях - например, для использования ее отладчика.

Работает ли оно в реальных производственных приложениях?

• Это довольно тяжело. Изучите свой выбор дизайна ДО написания моделей. Сделайте много исследований о хорошем дизайне Grails. Большинство вещей, которые я сделал два года назад, я могу понять, как сделать это лучше, потому что я более опытный. Он хорошо справляется с реальными производственными приложениями, но в зависимости от ошибок, которые вы совершаете, Hibernate может стать головной болью.