Стоит ли Грайлу?

Ответ 1

У нас была команда из 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 лет их существования они были столь же чреваты проблемой.

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

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

Ответ 2

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

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

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

Так много для плюсовой стороны. Минус-сторона - это производительность, которая поражает меня двумя аспектами: развертыванием и разработкой testdriven.

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Мне нравится простота использования плагинов для JMS, Quartz и Remoting, чтобы назвать несколько. Устраняет много утомительного XML.

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Python выглядит заманчивым, хотя, признаюсь.

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

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

Ответ 8

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

Ответ 9

Я был пользователем 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 при запуске проекта с нуля, я думаю, вы увидите его в другом свете.

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

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

Ответ 13

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

Ответ 14

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

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

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

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

Ответ 15

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

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