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

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

73 голосов
/ 13 января 2010

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

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

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

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

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

Спасибо

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

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

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

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

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

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

Ответы [ 21 ]

2 голосов
/ 14 января 2010

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

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

2 голосов
/ 13 января 2010

Плагин Grails Eclipse - это дерьмо. Он падает без всякой причины и не поддерживает гибкость Groovy. По слухам, NetBeans и IntelliJ намного лучше, но я их еще не пробовал.

Это работает? Конечно, это так. Даже Ruby on Rails работает, пока вы бросаете достаточно серверов на проблему. Я понятия не имею, как Grails сравнивается с различными средами Java.

Действительно ли это дает преимущества быстрой разработки? Ну, я все еще скучаю по многим хорошим материалам по Ruby / Rails. Он не распознает параметры запроса Date и Enum автоматически (опять же, у Rails также есть некоторые проблемы с датами), TimeCategory должна быть частью стандартной конфигурации, но это не так. Но есть также много вещей, которые требуют удивительно небольшой настройки.

Это не совсем то, где находится Rails (я особенно жду Rails 3), но работать с ним намного приятнее, чем со многими фреймворками Java. Тем не менее, магия под поверхностью идет глубже, чем в Rails. Например, система Constraints действительно мощная, но построена на огромном слое непроницаемых элементов Spring и действительно негибкая, если вы хотите использовать эту же мощность немного по-другому. Рельсы легче подорвать, IME.

Стоит ли это того? Да. Это лучший выбор, чем что-то еще? Это зависит.

2 голосов
/ 31 июля 2010

По моему опыту, в Grails есть несколько очень привлекательных функций, которые определенно заслуживают изучения и использования.

  • Ловкость - вещи, которые мы использовали для внедрения в обычные J2EE-проекты, обычно занимают целый день с помощью системы плагинов Grails. Такие вещи, как ajax, jquery ui, acegi, спокойная реализация, система планировщика и многие из них
  • Работает на JVM, что устраняет необходимость изучения какой-либо другой системы времени выполнения и ее особенностей
  • Синтаксис, подобный Java, и отличный синтаксис Sugar. как лучшее из обоих миров. Вы можете сразу начать с Java вместо изучения синтаксиса нового языка, такого как Ruby, а затем постепенно переходить к отличному синтаксису, который является надежным, простым и интуитивно понятным

    Для менеджеров проектов, если нет веских причин для «не использовать» grails по какой-либо причине (сопротивление со стороны высшего, принять новую технологию или что-то в этом роде), я не вижу никакой причины, по которой grails не могут быть использовался или хотя бы попробовал.

Чтобы ответить на вопрос об отладке, это не так сложно. Отладка проста, если вы используете IDE Netbeans. Это подводит меня к еще одному замечанию. После нескольких экспериментов со всеми IDE мы обнаружили, что Netbeans является наиболее подходящим для этой работы. В нем улучшена поддержка автозавершения кода, подсветки синтаксиса, отладки и т. Д. На мой взгляд, STS недостаточно хорош для этого.

1 голос
/ 17 января 2010

Что касается плагина eclipse, он еще не закончен, но вы можете использовать версию eclipse из Spring Source (SpringSource Tool Suite)

http://www.springsource.com/products/sts

Это вполне прилично по сравнению с предыдущими версиями плагинов, и с тех пор, как Spring Source приобрела компанию, ответственную за grails и groovy, можно ожидать, что STS быстро станет лучше

1 голос
/ 13 января 2010

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

Он значительно улучшился за последний год.В декабре я посетил Groovy & Grails Exchange в Лондоне.Был большой разговор по поводу интеграции Groovy & Grails в Eclipse / SpringSource STS, который был записан, см. видео .

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

1 голос
/ 30 марта 2011

Лично я выучил RoR и использовал его для нескольких домашних проектов, но затем переключился на Grails, в основном потому, что он работает на JVM, и поэтому я надеюсь использовать множество программ производительности / профилирования Java, которые должныпомогите выявить любые узкие места в коде, прежде чем они станут проблемой.

В общем, я не нашел слишком большой разницы в качестве IDE, используемых RoR против Grails.Хотя, если честно, я программирую на Linux и не пробовал TextMate для разработки RoR.Когда я использовал RoR, я использовал Netbeans.

Прямо сейчас я программирую с использованием STS и считаю, что использовать Grails с удовольствием, хотя я все еще нахожу, что обнаружение / завершение метода можно сделать намного лучше.

0 голосов
/ 23 января 2017

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

Это все еще ужасно. Я не знаю их начало, но миграция из Grails 2 в Grails 3 все еще кошмар, и они ломают больше, чем решают.

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

Я потратил один час на создание тестов Grails для вывода чего-либо в консоль (это не работает из коробки), даже в Java вы не потратите такое количество времени на вывод чего-либо из тестов.

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

Я до сих пор не знаю ни одной известной компании, которая бы что-то строила с Grails.

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

Я понятия не имею, почему кто-то еще использует Eclipse, но поддержка IntelliJ для Grails 3 просто не работает.

Итак, отвечая на главный вопрос:

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

Если вы не можете позволить себе лицензию Microsoft Access, возможно. Для реальных проектов я бы держался подальше от Грааля. На самом деле это просто мертворожденный ребенок.

0 голосов
/ 26 сентября 2013

Из моего опыта на конец 2013 года.

Плюсы

  • когда вы используете очень мало плагинов и ограничиваете наборы Grails no-s и never-s, это довольно плавный опыт разработки

Против

  • Обновление (F5) всегда является проблемой. И это самое раздражающее. По какой-то причине мне пришлось перезапускать сервер при каждом 3-4-м обновлении. Существует известная ошибка перезапуска: question1 , question2 , хотя это случается редко.
  • Ошибки уровня языка. Когда я использовал статические внутренние классы, мне всегда нужно было перезапускать сервер при изменении. Хотя проблем со сборкой нет, использование языка ограничено
  • время запуска, время сборки, размер приложения (70 мегабайт для небольшого приложения), использование памяти
  • только удаленная отладка, отладка IDE очень нестабильна
0 голосов
/ 26 июня 2013

Я хочу отметить еще два момента: использование памяти и рынок труда. Приложение Grails занимает много памяти, особенно в режиме разработки, например 600 Мб для приложений среднего размера. При развертывании в производственном режиме, например Военный файл в Tomcat, использование может быть около 500 Мб. Это частично унаследовано от использования Java.

Что касается рынка труда, и, насколько я читал, программисты Grails в объявлениях о вакансиях не пользуются большим спросом, например Django и Ruby on Rails.

0 голосов
/ 11 октября 2012

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

Я рекомендую посмотреть на что-то вроде ратпака, который намного легче, почти как синатра для рубина.

...