답변:
Grails의 가장 약한 부분 인 IMO는 데이터 모델 마이그레이션 기능 (ala Rails ActiveRecord 마이그레이션)이 부족했습니다. 다양한 품질 수준의 타사 플러그인이 있었지만 공식적인 것은 없었습니다.
그러나 방금 Liquibase가 확장되어 데이터베이스 마이그레이션 플러그인으로 바뀌 었으며 유망한 것으로 보입니다. http://www.grails.org/plugin/database-migration
플러스 측면에서 Grails를 사용한 모든 것 (간단하고 복잡한 웹 앱)에 대해서는 대부분 환상적이었습니다. Java / Hibernate / Spring / Spring MVC 스택에 비해 개발 생산성이 약 2 배에서 3 배 증가 할 수 있다고 말하고 싶습니다.
grails 환경을로드하는 데 시간이 걸리고 테스트를 실행하는 데 약간의 시간 만 소요되므로 통합 테스트 실행이 느려졌습니다. 이렇게하면 DB에 쓰는 코드를 개발할 때 처리 시간이 늘어납니다. 다른 문제는 Kaleb에 의해 그의 데이터 답변에 대해 이미 언급되었습니다. 또한 문제가 생길 때마다 최대 절전 모드와 봄에 사용할 수있는 도움말과 비교할 때 도움을받을 수있는 포럼이 제한적이라는 것을 알았습니다.
현재 프레임 워크를 사용하는 데 따른 함정은 현재 gradle 빌드 시스템에 제대로 통합되지 않은 것입니다. 현재 플러그인을 사용 하여이 작업을 수행하지만 플러그인 자체는 새로운 버전의 grails와 충돌합니다 (최근에 사용하고 수정하려고 시도한 것처럼). 그들은 graants 빌드 시스템 (gant 대신)을 gradles의 일부로 만들어 향후 버전에서이 문제를 해결할 계획이지만, 쉽게 통합 할 수있는 빌드 시스템이 없다는 것이 문제입니다. 그러나이 함정은 앞으로 사라질 것입니다.
또 다른 함정은 언어의 동적 인 특성입니다. 당신은 정말로 모든 것에 대한 테스트를 작성해야합니다. 코드에서 대부분의 오류는 런타임에 발견됩니다. 실제로 프로그램에 대해 생각하는 방식이 다릅니다. 이 프레임 워크에서는 발생하지 않는 실수를 찾기 위해 컴파일러에 의존합니다. 나는 그것이 나쁜 것이라고 말하지 않고, 단지 다릅니다 (그리고 익숙하지 않으면 함정).
나는 개인적으로 성배보다 평범한 그루비를 많이 사용했지만 전체 성배 / 그루비 개념을 좋아합니다.
내 개인적인 경험에서 유일한 단점은 IDE 지원이 부족하다는 것입니다. 나는 SpringSource가 훌륭한 Eclipse 빌드를 가지고 있으며 Grails를 강력하게지지하는 사람이라고 생각하면서 (낙관적으로) 생각했습니다. groovy 플러그인은 설치하기가 어렵고, 코드 완성이 불완전합니다 (항상 동적 언어의 문제이지만 60 가지 방법 중 하나를 선택하는 것이 도움이되지 않습니다), 종종 groovy의 내부 코드를 단계별로 실행해야하므로 디버깅이 지루할 수 있습니다. 최신 릴리스에서 groovy 플러그인을 설치하면 Java 디버거가 중단됩니다!