Ответы:
IMO, самой слабой частью Grails было отсутствие функциональности миграции модели данных (аля миграции Rails ActiveRecord). Были некоторые сторонние плагины разного уровня качества, но ничего официального.
Однако я только что обнаружил, что Liquibase был расширен и превращен в плагин для переноса базы данных, и это выглядит многообещающе: http://www.grails.org/plugin/database-migration
С другой стороны, для всего, что я использовал для Grails (простые и умеренно сложные веб-приложения), это было в основном фантастически. Я бы сказал, что могу увеличить производительность разработки примерно в 2–3 раза по сравнению со стеком Java / Hibernate / Spring / Spring MVC.
Выполнение интеграционных тестов было медленным, поскольку среда grails загружается, и для выполнения теста требуется только небольшая часть этого времени. Это увеличит время оборота при разработке кода, который пишет в базу данных. Другая проблема уже упоминалась Калебом в его ответе (о переносе данных). Я также обнаружил, что всякий раз, когда я застревал, количество форумов, на которые я мог получить помощь, было ограниченным по сравнению с помощью, доступной для спящего и весеннего периодов.
В настоящее время ловушкой использования фреймворка является его слабая интеграция в систему сборки gradle. В настоящее время он использует плагин для достижения этой цели, но сам плагин ломается с новыми версиями Grails (как я недавно пытался использовать и исправить). Они планируют решить эту проблему в будущей версии, сделав gradle частью системы сборки grails (вместо gant), но проблема в отсутствии системы сборки, которую вы можете легко интегрировать, является проблемой. Однако эта ловушка исчезнет в будущем.
Другая ловушка - динамическая природа языка. Вы действительно ДОЛЖНЫ написать тесты для всего. Большинство ошибок в вашем коде находятся во время выполнения. Это действительно другой способ мышления о программе. Опираясь на компилятор, чтобы найти некоторые из ваших ошибок не бывает с этим фреймворком. Я не говорю, что это плохо, это просто другое (и ловушка, если вы с ней не знакомы).
Мне нравится концепция цельного грааля / шпунта, хотя лично я использовал простой шпунт больше, чем грааля, я думаю, что они оба великолепны.
Единственный недостаток (по моему личному опыту) - плохая поддержка IDE. Я думал (довольно оптимистично), что, поскольку SpringSource имел отличную сборку Eclipse и были твердыми сторонниками Grails, это будет путь. Плагины Groovy сложны в установке, завершение кода нестабильно (всегда проблема с динамическими языками, но выбор из 60 методов не так уж полезен), отладка может быть утомительной, поскольку часто требует пошагового выполнения внутреннего кода groovy, и, В последнем выпуске установка Groovy плагин ломает отладчик Java!
В настоящее время он имеет слабую поддержку абстрактных классов. Например, вы не можете связать список реализаций в единый List<T>объект команды. Конечно, это в первую очередь раздражает, потому что я привык к тому, что магически связываю все остальное! : D
Как правило, это все еще просто "зеленый"; вы в конечном итоге сталкиваетесь со странными небольшими ограничениями и ошибками. Это действительно прошло долгий путь через несколько лет.