Стоит ли того Grails?

У нас была команда из 12 человек, состоящая из опытных старших разработчиков Java, которые изучили Grails из 0.6B, и все мы все еще работаем над проектами, основанными на Grails. Я бы не стал охотно возвращаться к Java, и мы все рады, что сломали основу того, как быстро добраться до чего-то с помощью приложения Grails.

Это была борьба, это было нелегко, и было / есть разочарование.

Тем не менее, мы сделали кое-что очень быстро, учитывая наши постоянные усилия. Есть ошибки, многие из которых имеют обходные пути.

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

В конце концов мы создали нечто огромное и сложное, которое сказочно работало и работало намного быстрее, чем написание чистой версии Java / Spring / Hibernate; И это без достойной поддержки IDE и гораздо худшая ситуация с точки зрения ошибок, чем сегодня.

Что касается поддержки Eclipse, единственная настоящая среда IDE, которую можно использовать для Grails / Groovy, - это Intellij - поддержка Eclipse, к сожалению, сильно отстает: я был любителем Eclipse и далек от преобразования Intellij - поддержка Grails / Groovy сдувает все остальное хотя.

Да, Grails, пожалуй, незрелый по сравнению со Spring. Или спящий режим. И я готов поспорить, что в первые 1,5 года своего существования они были столь же чреваты проблемами.

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

Когда вы задействуете Spring / Hibernate в стеке, для Java не существует быстрого решения кода. Сложность, которую воплощает в себе Grails, является отражением собственной сложности Spring / Hibernate. Если вы чувствуете, что вам лучше потратить время на это с чистой Java, я бы не стал спорить иначе ... У меня все еще есть свои WTF, но теперь, когда крутая кривая обучения позади, я думаю, что я буду придерживаться Grails еще немного.

Мне очень нравится писать приложение Grails по двум причинам:

• Мне не нужно использовать Java
• Я могу использовать Java

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

Вот и все о плюсах. Минусом является производительность, которая поражает меня по двум аспектам: развертывание и разработка через тестирование.

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

К тому же испытатель грааля не заслуживает этого имени. Когда я запускаю модульные тесты, они должны выполняться мгновенно, а не за 10–20 секунд. Так что я все время пишу бизнес-логику на простом языке java, потому что могу тестировать ее намного быстрее. Но я предполагаю, что это можно решить с помощью лучшей интеграции в IDE (eclipse).

Я думаю, что поддержка Grails в Spring будет большим стимулом. Если кто-то и может пройти мимо CRUD в сети, так это те ребята.

Я тоже считаю, что он достигает критической массы. Есть несколько новых книг, которые выйдут на рынок в 2009 году. Я думаю, что они улучшат скорость их принятия.

Я полностью согласен с первоначальными настроениями постеров.

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

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

Действительно неприятно, когда код выходит из строя без единого сообщения об ошибке! Это просто не работает, и вы не знаете почему?

Мне нравится простота использования плагинов для JMS, Quartz и Remoting, и это лишь некоторые из них. Откажется от утомительного XML.

Мне почти нравится GORM за его простоту, хотя у нас тоже было несколько проблем.

Мне не нравится слабо типизированная природа Groovy, и тот факт, что вам нужно запускать свое приложение, чтобы иметь возможность отловить кучу ошибок, слишком напоминает мне PHP или Rails.

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

У нас есть приложение Grails, которое будет запущено в производство… так что посмотрим.

Мы используем grails + на веб-слое + java с hibernate и spring на сервисном слое. Это классические три слоя (сеть, логика, данные), где сеть представляет собой грааль, а логика реализована на языке java. Как обычно в java, мы используем объекты bean-компонентов, которые представляют данные между разными уровнями.

Он работает очень хорошо, и это было лучшее решение для нашего случая, так как объекты bean-компонентов уже были там, как и структура базы данных. Исходя из нашего опыта, я считаю, что grails имеет большую ценность как слой веб-презентации, но я бы придерживался java, чтобы писать бизнес-правила и сохранять данные приложения - поскольку grails «есть» java, вся интеграция grails-java довольно хороша. простой.

Мы используем eclipse для разработки приложения grails, и, как здесь говорят, у него плохая интеграция. Но, как предложение от другого разработчика, мы запускаем приложение grails из командной строки и используем eclipse только для сохранения исходных файлов, и он работает очень хорошо, поскольку приложение обновляется на лету.

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

У меня гораздо больше опыта работы с Ruby on Rails, чем с чем-либо в мире Java, поэтому я подхожу с другой точки зрения. В целом, Grails гораздо более грубоват, чем Rails, частично из-за своей незрелости, а частично из-за того, что он опирается на две безумно сложные внутренние структуры (Spring и Hibernate). . Rails также имеет гораздо большее сообщество.

Но Groovy как язык добился огромных успехов, и с ним приятно работать. Благодаря улучшениям, внесенным в Groovy 1.6, Grails немного быстрее, чем JRuby on Rails, и вы получаете потрясающе хорошую поддержку XML через GPath. Есть много приятных функций, которые вы получаете, находясь на JVM (например, параллелизм и тонны потоковобезопасного кода), но без необходимости возиться с Java (язык, который мне не очень нравится), поэтому у меня действительно Трудно убедить себя использовать что-нибудь на МРТ.

Хотя, должен признать, Python выглядит заманчиво.

Что касается ваших проблем с Eclipse, я ничем не могу помочь. Я использую Vim и Emacs, в основном потому, что терпеть не могу использовать IDE. Однако для динамических языков, таких как Groovy, Ruby и Python, я не думаю, что IDE действительно приносят какую-либо реальную пользу, поскольку на самом деле нет места для генерации кода или необходимости компиляции. Может быть, попробовать какое-то время поработать без IDE и посмотреть, будет ли все гладко?

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

Я полностью с тобой! Grails по-прежнему кажется настолько грубым, что сравнивать его с Rails - почти шутка. Если бы хотя бы отчет об ошибках был немного лучше. Но я предполагаю, что это, вероятно, также связано с огромным количеством библиотек, которые он использует под обложками. Одно слово: stacktrace! Я также не большой поклонник подхода model-> db (в Rails есть db-> model). Строительные леса также оставляют много возможностей для улучшения. Тогда "перезагрузка не требуется" также не работает, как рекламируется. (Я не уверен, что хуже - необходимость все время перезагружать или иногда обнаруживать странное поведение, которое исчезает при перезапуске) И не заставляйте меня запускать GORM. (Когда требуются часы, чтобы найти способ, который был бы простым SQL, вы начинаете задаваться вопросом, действительно ли весь этот ORM экономит ваше время) Может быть, если это просто.

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

В любом случае - будем надеяться, что с этим разберутся. В настоящий момент я прячусь на playframework.org, который также выглядит очень привлекательно и многообещающе.

Оно того стоит, когда они доделают плагин eclipse. Чем раньше, тем лучше я скажу. Пока этого не произойдет, будет непросто продать отличный мой босс.

Я считаю, что самым большим преимуществом Grails является то, что мне больше не нужно заботиться о базе данных - схема автоматически создается / обновляется, а постоянство в значительной степени выполняется за меня (больше не нужно писать SQL-запросы). Это огромное облегчение. Еще одна вещь, которая довольно хороша, заключается в том, что после того, как вы остановились на шаблонах для контроллеров и представлений, добавление новых объектов домена происходит довольно быстро. Хотя я подозреваю, что вы будете вносить постоянные изменения, по крайней мере, в свои представления, подгоняя их под существующие.

Что касается IDE - кажется, что IntelliJ - лучший вариант, но я доволен использованием Netbeans 6.5. Я использую MyEclipse для всех остальных разработок, но теперь Netbeans имеет лучшую поддержку Grails.

Я был пользователем Eclipse до того, как начал использовать Grails. Быстро стало очевидно, что это не поможет. Итак, я попробовал Intellij и NetBeans. В то время Intellij был лучше в плане Groovy и Grails. Однако NetBeans был бесплатным, и этого для меня было достаточно. С тех пор для всех трех были выпущены новые версии или новые плагины. Я все еще использую NetBeans из-за стоимости Intellij. С приобретением G2One компанией Spring Source одно из ожиданий заключается в большей поддержке Groovy и Grails в Eclipse. Это будет необходимо для более широкого внедрения.

Замечательно использовать Grails для нового проекта. Больше нет необходимости в багаже ​​Enterprise Java. Я могу представить, что попытка портировать что-то будет сложной задачей, потому что, пока вы не поймете сильные и слабые стороны фреймворка, его будет сложно использовать эффективно. Обещано, что поддержка JSP станет проще в Grails 1.1, я не знаю, стоит ли использовать бета-версию при попытке попробовать новый фреймворк. Тестирование также претерпело серьезные изменения для новой версии. Если позволяет время, вы можете подождать, так как релиз 1.1 должен быть очень скоро.

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

Я только начал использовать grails в новом проекте ... мне не нужно писать ЛЮБЫЕ XML-файлы, но при этом у меня все еще есть возможности Spring, а Hibernate действительно потрясающий.

Используйте IntellijIDEA для IDE, хотя я фактически обнаружил Grails через IDE (хотя я могу быть предвзятым, я ненавижу eclipse).

Полностью. Существует так много фреймворков Java, что планка для новичков достаточно высока, и Grails свидетельствует о том, что он смог подняться выше в таком переполненном пространстве.

У него все еще есть несколько острых граней, но это всего лишь вопрос времени, прежде чем они станут матовыми, основной проект ОЧЕНЬ того стоит.

Grails может оказаться слишком большим для вашего типа приложения (в зависимости от количества файлов, созданных при первой инициализации, и требуемых ресурсов). Если вы ищете что-то простое, Grails может оказаться не тем, что вам нужно. Если вы ищете что-то простое и работающее, я считаю, что django отлично справится с вашей работой. Посмотрите, насколько просто (сколько файлов для этого требуется) создавать приложения CRUD из его руководство. Отсюда ваши приложения можно (относительно) легко масштабировать по мере роста ваших потребностей и требований.

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

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

В конце концов, вы разочарованы, потому что не хотите даже прикасаться ни к чему, что работает. А то, что не очень хорошо, вы бросаете!

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

Если ваш опыт в Java, как вы говорите. Вам стоит взглянуть на Play Framework - это веб-фреймворк, вдохновленный Ruby on Rails с очень коротким циклом разработки. - просто сохраните исходный файл Java и обновите веб-браузер. А если вы хотите попробовать другой язык, в Play Framework есть модуль, позволяющий использовать вместо него Scala.

Мне нравится Play Framework, потому что он прост для понимания и имеет хорошую производительность. Вы также можете использовать JPA и Hibernate для уровня ORM, если хотите.