Это наполовину напыщенная речь, наполовину вопрос.
Стоит ли использовать Grails? Я пытаюсь разработать относительно простое веб-приложение на основе базы данных. Я специализируюсь на Java, поэтому, естественно, Grails показался мне хорошим выбором. Сначала я думал об использовании Spring, JPA и Hibernate, но я использовал это раньше и столкнулся со всеми видами утомительной работы по настройке и кодированию. Grails рекламирует себя как решение этой проблемы.
Мое самое большое разочарование в Grails - это мелочи, которые не работают. Я имею в виду, что это не работает так, как можно было бы интуитивно подумать. Он очень грубый по краям. Постоянно сталкиваюсь с проблемами. Иногда это мое непонимание Grails - иногда я обнаруживал настоящие ошибки Grails.
Одна из основных проблем - отсутствие хорошей интеграции с Eclipse. Есть плагин Groovy и Grails, но он не делает ничего, кроме подсветки синтаксиса. Вызов Groovy из Java и наоборот очень болезненно настраивать . Отсутствие хорошей поддержки IDE - серьезный облом.
Я сажусь за разработку своего веб-приложения. В конце концов, я понимаю, что потратил около 85% дня на отладку проблем, связанных с Grails. Если это не проблемы Eclipse , то это жадная загрузка , выборка в представлении , один-ко-многим , странной пустому поведение файла ошибка , странное свойство / геттер ошибка - это просто идет дальше и дальше. Это всего лишь образец проблем, с которыми я столкнулся сегодня. Моя последняя встреча с Grails вызвала кучу разных проблем.
Иногда я задаюсь вопросом, стоит ли оно того. Мне любопытно, испытывали ли это другие. Есть ли люди, которые действительно используют 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 по двум причинам:
Я думаю, что после знакомства с 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, если хотите.
источник