Odpowiedzi:
IMO, najsłabszą częścią Grails był brak funkcji migracji modelu danych (m.in. migracje Rails ActiveRecord). Było kilka wtyczek innych firm o różnym poziomie jakości, ale nic oficjalnego.
Jednak właśnie odkryłem, że Liquibase został rozszerzony i przekształcony we wtyczkę do migracji bazy danych, i wygląda to obiecująco: http://www.grails.org/plugin/database-migration
Plusem jest to, że wszystko, do czego korzystałem z Grails (proste do umiarkowanie skomplikowane aplikacje internetowe), było w większości fantastyczne. Powiedziałbym, że mogę uzyskać około 2x do 3-krotny wzrost produktywności w porównaniu do stosu Java / Hibernate / Spring / Spring MVC.
Uruchamianie testów integracyjnych przebiegało powoli, ponieważ środowisko Grails wymaga czasu na załadowanie i do uruchomienia testu potrzeba tylko ułamka tego czasu. Zwiększy to czas zmiany podczas tworzenia kodu, który zapisuje do bazy danych. Drugi problem został już wspomniany przez Kaleba w jego odpowiedzi (dotyczącej migracji danych). Odkryłem również, że ilekroć utknąłem, liczba forów, na których mogłem uzyskać pomoc, była ograniczona w porównaniu z pomocą dostępną w hibernacji i wiośnie.
Obecnym problemem związanym z korzystaniem z frameworka jest jego słaba integracja z systemem budowania stopni. Obecnie korzysta z wtyczki, aby to osiągnąć, ale sama wtyczka łamie się z nowymi wersjami grails (jak ostatnio próbowałem użyć i naprawić). Planują naprawić ten problem w przyszłej wersji, wprowadzając stopień do systemu kompilacji Grails (zamiast Gant), ale problemem jest brak systemu kompilacji, który można łatwo zintegrować. Jednak pułapka ta zniknie w przyszłości.
Kolejną pułapką jest dynamiczna natura języka. Naprawdę MUSISZ napisać testy na wszystko. Większość błędów w kodzie znajduje się w czasie wykonywania. To naprawdę inny sposób myślenia o programie. Poleganie na kompilatorze w celu znalezienia niektórych błędów nie zdarza się w tym frameworku. Nie twierdzę, że jest zły, jest po prostu inny (i pułapkę, jeśli go nie znasz).
Podoba mi się koncepcja całych grails / groovy, chociaż osobiście używałem zwykłego groovy bardziej niż grails. Sądzę, że oba są wspaniałe.
Jedynym minusem (moim osobistym doświadczeniem) jest słaba obsługa IDE. Pomyślałem (raczej optymistycznie), że skoro SpringSource miał doskonałą kompilację Eclipse i mocno wspierał Grailsa, to byłaby dobra droga. Groovy wtyczki są trudne do zainstalowania, uzupełnianie kodu jest niestabilne (zawsze problem z dynamicznymi językami, ale wybór 60 metod nie jest zbyt pomocny), debugowanie może być żmudne, ponieważ często wymaga przejścia przez wewnętrzny kod groovy, i, w najnowszej wersji instalacja groovy plugin psuje debugger Java!
Obecnie ma słabą obsługę klas abstrakcyjnych. Na przykład nie można powiązać listy implementacji w jeden List<T>obiekt obiektu polecenia. Oczywiście jest to przede wszystkim denerwujące, ponieważ przywykłem do magicznego wiązania wszystkiego innego! :RE
Generalnie jest to po prostu rodzaj „zielonego”; w końcu napotykasz dziwne ograniczenia i błędy. Ale za kilka lat to naprawdę długa droga.