Grails는 그만한 가치가 있습니까? [닫은]

반쯤 호언 장담하고 반은 질문입니다.

Grails를 사용할 가치가 있습니까? 비교적 간단한 데이터베이스 기반 웹 애플리케이션을 개발하려고합니다. 내 전문 지식은 Java에 있으므로 자연스럽게 Grails가 좋은 선택처럼 보였습니다. 처음에는 Spring, JPA 및 Hibernate를 사용하려고 생각했지만 이전에 사용했으며 모든 종류의 지루한 구성 및 코딩 작업을 수행했습니다. Grails는이를 해결하는 것으로 스스로를 광고합니다.

Grails에 대한 저의 가장 큰 좌절감은 작동하지 않는 작은 모든 것입니다. 내 말은 직관적으로 생각하는 것처럼 작동하지 않는다는 것입니다. 가장자리가 매우 거칠다. 나는 끊임없이 문제에 부딪친 다. Grails에 대한 이해가 부족한 경우도 있습니다. 합법적 인 Grails 버그를 발견 한 경우도 있습니다.

한 가지 주요 문제는 좋은 Eclipse 통합이 없다는 것입니다. Groovy 및 Grails 플러그인이 있지만 구문 강조 외에는 많은 기능을 수행하지 않습니다. Java에서 Groovy를 호출하거나 그 반대로 호출하는 것은 구성 하기가 매우 어렵습니다 . 좋은 IDE 지원이 없다는 것은 큰 문제입니다.

웹 응용 프로그램을 개발하려고 앉아 있습니다. 하루가 끝날 무렵 Grails 관련 문제를 디버깅하는 데 하루의 약 85 %를 소비했다는 것을 알게되었습니다. 이클립스 문제가 아니라면 eager loading , fetching in the view , 일대 다 관계 , 이상한 빈 파일 버그 동작 , 이상한 속성 / 게터 버그 -그냥 계속됩니다. 이것은 내가 오늘 만난 문제의 샘플에 불과합니다. 마지막으로 Grails를 사용하면서 여러 가지 문제가 발생했습니다.

나는 때때로 그만한 가치가 있는지 궁금합니다. 다른 사람들이 이것을 경험했는지 궁금합니다. 실제로 Grails를 사용하여 웹 애플리케이션을 생산적으로 구축하는 사람들이 있습니까? 빠른 웹 개발을 위해 고려해야 할 다른 프레임 워크가 있습니까?

0.6B에서 Grails를 배운 노련한 Java 개발자 12 명으로 구성된 팀이 있었으며 우리 모두는 여전히 Grails 기반 프로젝트를 진행하고 있습니다. 저는 기꺼이 Java로 돌아 가지 않을 것이며, Grails 앱으로 빠르게 어딘가로 이동하는 방법을 망가 뜨린 것에 대해 모두 안심하고 있습니다.

투쟁이었고 쉽지 않았고 좌절감이있었습니다.

그럼에도 불구하고 우리는 우리의 지속적인 노력을 감안할 때 매우 빠르게 무언가를 제공했습니다 .. 해결 방법이있는 버그가 많이 있습니다.

저는 Java에 능숙한 개발자들이 Grails 프로젝트의 깊고 복잡한 주문에 뛰어 들려고하는 여러 사례를 들었습니다. 우리는 모든 Java를 피하고 pure-Grails와 Groovy를 사용했습니다. 우리는 단순하게 시작하고 가능한 한 관리하기 쉽고 실질적으로 복잡성을 구축했습니다. 우리는 감히 가장 깊이 빠져들지 않았으며 Java 지식이 우리를 충분히 이끌 수 있기를 바랍니다.

우리는 결국 엄청나게 작동하는 거대하고 복잡한 것을 만들었고 순수한 Java / Spring / Hibernate 버전을 작성하는 것보다 훨씬 빠르게했습니다. 그리고 그것은 적절한 IDE 지원이없고 오늘날보다 버그 측면에서 훨씬 더 나쁜 상황입니다.

Eclipse 지원과 관련하여 Grails / Groovy에 사용할 수있는 유일한 IDE는 Intellij입니다. 이클립스 지원은 슬프게도 뒤쳐져 있습니다. 저는 Eclipse 애호가 였고 Intellij 변환과는 거리가 멀습니다. Grails / Groovy 지원은 다른 모든 것을 날려 버립니다. 그러나.

예, Grails는 아마도 Spring에 비해 미숙합니다. 또는 최대 절전 모드. 그리고 나는 그들의 존재의 첫 1.5 년 동안 그들은 똑같이 문제로 가득 차 있었다고 장담합니다.

그 자체로, 복잡성을 최소한으로 유지하고 신중하게 테스트 우선 (우리의 의견)을 세 심하게 테스트하고 점차적으로 신중하게 복잡성을 구축 할 책임이 있습니다.

스택에 Spring / Hibernate를 포함 시키면 Java로 빠른 코드 솔루션이 없습니다. Grails가 구현하는 복잡성은 Spring / Hibernate 자체의 복잡성을 반영합니다. 순수한 Java로 시간을 보내는 것이 더 낫다고 생각한다면 다른 방법으로 주장하지 않을 것입니다. 저는 여전히 제 WTF를 가지고 있지만 이제는 가파른 학습 곡선이 제 뒤에 있기 때문에 Grails에 좀 더 집중할 것이라고 생각합니다.

나는 두 가지 이유로 성배 신청서를 작성하는 것을 매우 좋아합니다.

• Java를 사용할 필요가 없습니다.
• Java를 사용할 수 있습니다.

성배에 익숙해지면 그의 일을 매우 빠르고 우아하게 처리 할 수 ​​있다고 생각합니다.

플러스 측에 너무 많이. 마이너스 측면은 성능으로, 배포 및 테스트 기반 개발이라는 두 가지 측면에서 저를 감동시킵니다.

메모리 및 성능 제한에 빠르게 도달했기 때문에 단일 (대여) 서버에서 3 개 이상의 grails 애플리케이션을 실행하지 못했습니다. 너무 많은 프레임 워크가 포함되어 있습니다.

또한 성배의 테스트 러너는 그 이름의 가치가 없습니다. 단위 테스트를 실행할 때는 10 ~ 20 초가 아닌 즉시 수행해야합니다. 그래서 나는 그것을 훨씬 더 빨리 테스트 할 수 있기 때문에 항상 평범한 자바로 비즈니스 로직을 작성하고 있다는 것을 알게된다. 하지만 IDE (eclipse)에 더 잘 통합하면이 문제를 해결할 수 있다고 생각합니다.

Spring의 Grails 지원이 큰 도움이 될 것이라고 생각합니다. 누구든지 웹에서 CRUD를 지나서 이동할 수 있다면 그 사람입니다.

나는 또한 그것이 임계 질량에 도달하고 있다고 생각합니다. 2009 년에 시장에 출시 될 몇 가지 새로운 책이 있습니다. 이러한 책이 채택률에 도움이 될 것입니다.

나는 원래 포스터 감정에 전적으로 동의합니다.

우리는 Java + Spring 상점이며 Grails를 사용해 볼 기회를 얻었습니다. 우리는 처음에 매우 간단한 테스트 응용 프로그램을 만들었으며 매우 잘 작동했습니다. 여기서 우리가 겪었던 주요 문제는 Groovy와 Grails에 대한 지식이 부족했기 때문입니다.

이 성공 (신뢰도 향상) 후에 우리는 약간 더 큰 프로젝트를 시도하기로 결정했습니다. 이것은 훨씬 더 고통스러운 경험이었습니다. 다른 사람들이 언급했듯이, 우리는 표면에서 즉시 드러나지 않는 모든 종류의 버그와 문제를 발견했습니다. 앱 다시 시작주기는 매우 고통스럽고 테스트 범위가 정말 좋지 않으면 모든 종류의 리팩토링을 수행하는 것은 악몽입니다.

정말 실망스러운 것은 단일 오류 메시지없이 코드가 실패하는 것입니다! 작동하지 않고 이유를 모르십니까?

JMS, Quartz 및 Remoting 용 플러그인의 사용 편의성이 마음에 듭니다. 지루한 XML을 많이 사용하지 않습니다.

몇 가지 문제가 있지만 GORM의 단순성 때문에 거의 좋아합니다.

저는 Groovy의 느슨하게 형식화 된 특성과 많은 오류를 잡기 위해 애플리케이션을 실행해야한다는 사실이 마음에 들지 않습니다. PHP 또는 Rails를 너무 많이 상기시킵니다.

결국 우리는 Grails를 사용하여 복잡한 관리 가능한 소프트웨어를 작성할 수 있는지 자문합니다.

우리는 곧 프로덕션에 들어갈 Grails 애플리케이션을 가지고 있습니다.

우리는 grails + on the web layer + java with hibernate and spring on the service layer를 사용하고 있습니다. 웹이 성배하고 로직이 Java로 구현되는 고전적인 세 계층 (웹, 로직, 데이터)입니다. 자바에서 평소처럼 우리는 서로 다른 레이어 사이의 데이터를 나타내는 빈 객체를 사용합니다.

그것은 꽤 잘 작동하고 빈 객체가 이미 거기에 있고 데이터베이스 구조가 있기 때문에 우리의 경우에 가장 좋은 솔루션이었습니다. 경험상 grails는 웹 프리젠 테이션 레이어로서 큰 가치를 가지고 있다고 생각하지만, 비즈니스 규칙을 작성하고 애플리케이션 데이터를 유지하기 위해 Java를 고수 할 것입니다. grails가 "자바"이므로 모든 grails-java 통합은 꽤 좋습니다 똑바로.

우리는 이클립스를 사용하여 grails 응용 프로그램을 개발하고 사람들이 여기에서 말했듯이 통합이 좋지 않습니다. 그러나 다른 개발자의 제안으로, 우리는 명령 줄에서 grails 애플리케이션을 실행하고 이클립스 만 사용하여 소스 파일을 저장하고 애플리케이션이 즉시 업데이트되므로 꽤 잘 작동합니다.

나는 아직 프레젠테이션 레이어가 아닌 다른 장소에서 grails를 사용하는 것이 편하지 않다.

Java 세계에서하는 것보다 Ruby on Rails에 대한 경험이 훨씬 많기 때문에 다른 관점에서 들어오고 있습니다. 전반적으로 Grails 는 Rails보다 훨씬 더 거칠다. 부분적으로는 미성숙으로 인한 것이고 부분적으로 엄청나게 복잡한 두 프레임 워크 (Spring 및 Hibernate)에 의존하기 때문이다. Rails에는 훨씬 더 큰 커뮤니티가 있습니다.

그러나 언어로서의 Groovy는 큰 발전을 이루었고 함께 일하는 것을 기쁘게 생각합니다. Groovy 1.6의 개선 사항 덕분에 Grails는 JRuby on Rails보다 훨씬 더 빠르고 GPath를 통해 놀랍도록 훌륭한 XML 지원을 얻을 수 있습니다. JVM (동시성 및 수많은 스레드 세이프 코드와 같은)에 있으면 얻을 수있는 멋진 기능이 많이 있지만 Java (별로 신경 쓰지 않는 언어)를 사용하지 않아도됩니다. MRI에서 무엇이든 사용하도록 설득하기가 어렵습니다.

파이썬은 유혹적이지만 인정해야합니다.

Eclipse 문제에 관해서는 도와 드릴 수 없습니다. 저는 주로 IDE를 사용할 수 없기 때문에 Vim과 Emacs를 사용합니다. 하지만 Groovy, Ruby 및 Python과 같은 동적 언어의 경우 코드 생성이나 컴파일 할 필요가 없기 때문에 IDE가 실제로 실질적인 이점을 제공한다고 생각하지 않습니다. 잠시 동안 산세 IDE로 작업을 시도하고 일이 더 원활하게 진행되는지 확인 하시겠습니까?

예, Grails가 그만한 가치가 있다고 생각합니다. 그들은 일이 가능한 한 빨리 일을하도록하는데 헬 루바 일을 해왔고, Grails와 Groovy 팀은 둘 다 정말 정말 헌신적입니다.

나는 완전히 당신과 함께 있습니다! Grails는 여전히 가장자리가 너무 거칠어 서 Rails와 비교하는 것은 거의 농담입니다. 적어도 오류보고가 조금 더 좋았다면. 그러나 그것은 아마도 커버 아래에서 사용하는 엄청난 양의 라이브러리 때문일 것입니다. 한 단어 : stacktrace! 나는 또한 model-> db 접근 방식을 좋아하지 않습니다 (Rails에는 db-> model이 있습니다). 비계는 또한 개선의 여지가 많습니다. 그러면 "다시 시작하지 않아도 됨"도 광고 된대로 작동하지 않습니다. (더 나쁜 것이 무엇인지 잘 모르겠습니다. 항상 다시 시작해야하거나 다시 시작하면 사라지는 이상한 동작을 찾는 경우도 있습니다.) 그리고 GORM을 시작하지 마세요. (간단한 SQL이었을 방법을 찾는 데 몇 시간이 걸리면이 전체 ORM이 실제로 시간을 절약 할 수 있는지 궁금해지기 시작합니다.) 간단하다면 가능합니다.

내 말은 : 자바 세계에서 왔을 때 여전히 프레임 워크의 더 나은 선택 중 하나입니다. (자체를 웹 프레임 워크라고 부르는 쓸모없는 쓰레기) ... 잠재력이 있습니다. 다른 많은 복잡한 것들 위에 구축되지 않았 으면합니다.

어쨌든-이러한 것들이 정렬되기를 바랍니다. 현재 나는 매우 매끄럽고 유망 해 보이는 playframework.org에 숨어 있습니다.

eclipse 플러그인을 완료하면 그만한 가치가 있습니다. 빨리 말할수록 더 좋다. 그루비를 상사에게 팔려고하는 것은 그렇게 될 때까지 간단하지 않을 것입니다.

Grails의 가장 큰 장점은 더 이상 데이터베이스에 대해 신경 쓸 필요가 없다는 것입니다. 스키마는 자동으로 생성 / 업데이트되고 지속성은 대체로 수행됩니다 (더 이상 SQL 쿼리를 작성하지 않음). 이것은 큰 안도감입니다. 다른 좋은 점은 컨트롤러와 뷰에 대한 템플릿을 정한 후에는 새 도메인 개체를 추가하는 것이 매우 빠르다는 것입니다. 나는 당신이 적어도 당신의 견해에 대해 지속적인 변화를 할 것이라고 생각하지만, 그것들을 기존의 견해에 다시 맞추십시오.

IDE의 경우 IntelliJ가 최상의 옵션 인 것 같지만 Netbeans 6.5를 사용하는 것이 기쁩니다. 다른 모든 개발에는 MyEclipse를 사용하지만 Netbeans는 이제 더 나은 Grails 지원을 제공합니다.

Grails를 사용하기 전에는 Eclipse 사용자였습니다. 그것을 자르지 않을 것이라는 것이 금방 분명해졌습니다. 그래서 Intellij와 NetBeans를 사용해 보았습니다. 당시 Intellij는 Groovy와 Grails에 관한 한 더 좋았습니다. 그러나 NetBeans는 무료 였기 때문에 나에게 충분했습니다. 그 이후로 세 가지 모두 새 버전이나 새 플러그인이 출시되었습니다. Intellij의 비용 때문에 여전히 NetBeans를 사용하고 있습니다. Spring Source가 G2One을 인수하면서 기대 중 하나는 Eclipse의 Groovy 및 Grails에 대한 더 많은 지원입니다. 이는 채택을 늘리는 데 필요합니다.

새로운 프로젝트에 Grails를 사용하는 것은 훌륭합니다. 엔터프라이즈 Java 수하물의 많은 부분이 더 이상 필요하지 않습니다. 프레임 워크의 강점과 약점을 이해하기 전까지는이를 효율적으로 활용하기가 어렵 기 때문에 무언가를 이식하는 것이 어려울 것이라고 상상할 수 있습니다. Grails 1.1에서 JSP 지원이 더 쉬워 질 것이라고 약속했지만, 새로운 프레임 워크를 만들려고 시도하는 동안 베타 버전을 사용하는 것이 좋은 생각인지 모르겠습니다. 테스트는 또한 새 버전에 대한 주요 수정을 거쳤습니다. 시간이 허락한다면 1.1 릴리스가 곧 출시 될 것이므로 기다리는 것을 고려할 수 있습니다.

처음부터 프로젝트를 시작할 때 Grails를 다른 IDE에서 시도해 볼 수있는 기회가 있다면 다른 관점에서 보게 될 것이라고 생각합니다.

나는 방금 새 프로젝트에서 grails를 사용하기 시작했습니다. xml 파일을 작성할 필요가 없지만 여전히 Spring의 힘을 가지고 있으며 Hibernate는 정말 놀랍습니다.

IDE에 IntellijIDEA를 사용했지만 실제로 IDE를 통해 Grails를 발견했습니다 (편견이있을 수 있지만 이클립스가 싫습니다 ).

전적으로. 자바 프레임 워크가 너무 많아서 초심자를 위해 기준이 상당히 높게 설정되어 있으며, Grails가 그렇게 붐비는 공간에서 위로 올라갈 수 있다는 증거입니다.

여전히 날카로운 모서리가 몇 개 있지만, 그것들은 헝클어지기 전에 시간 문제 일 뿐이며, 기본 프로젝트는 그만한 가치가 있습니다.

Grails는 애플리케이션 유형에 따라 클 수 있습니다 (첫 번째 초기화에서 생성 한 수많은 파일과 필요한 리소스를 기반으로). 간단한 것을 찾고 있다면 Grails가 원하는 것이 아닐 수도 있습니다. 단순하고 작동하는 것을 찾고 있다면 지금까지 django가 당신의 일을 잘 할 수 있다고 생각합니다. 튜토리얼 에서 CRUD 앱을 만드는 데 얼마나 간단한 지 (필요한 파일 수)를 살펴보세요 . 여기에서 필요와 요구 사항이 증가함에 따라 앱을 (상대적으로) 쉽게 확장 할 수 있습니다.

나는 그들이 Grails를 당신이 아는 바에 맞게 만들 수 있을지 확신하지 못합니다. 그리고 결국에는 모든 세부 사항 (작고 큰 것)을 다루어 결국 부서지기 쉽고 연약하게 느껴집니다. 그 뒤에 실제 개발 팀 (2 명 이상을 의미)이 있는지조차 확신 할 수 없습니다.

Grails 프로젝트의 기능을 반복하면서 무언가를 개선하려고 할 때마다 동일한 워크 플로입니다. 모든 것이 무너지고 수백 번의 '구글'테스트주기가 발생하면 할 수없는 이유를 찾을 수 있습니다. 당신이 원하는 것과 다른 일을합니다.

결국, 당신은 실행되는 것을 만지고 싶지 않기 때문에 좌절합니다. 그리고 좋지 않은 것은 버리십시오!

JRuby를 통해 Rails로 전환하는 것을 고려하고 있습니다. 그것은 두 세계 모두에서 최고 일 수 있습니다. 활발하고 대규모 커뮤니티가있는 유능한 웹 프레임 워크, 전담 개발자 팀, Spring 또는 Hibernate와 같은 의심스럽고 복잡한 프레임 워크를 기반으로하지 않는 플랫폼, 빠르고 야심 찬 릴리스주기입니다. 그리고 JRuby는 솔직히 내 배낭에 너무 많은 Java 자산을 버릴 수 없기 때문입니다.

당신의 전문 지식이 당신이 말하는 것처럼 Java에 있다면. 아주 짧은 개발주기를 가진 Ruby on Rails에서 영감을받은 웹 프레임 워크 인 Play Framework를 봐야 합니다. Java 소스 파일을 저장하고 웹 브라우저를 업데이트하기 만하면됩니다. 그리고 다른 언어를 사용하고 싶다면 Play Framework에 Scala를 대신 사용할 수있는 모듈이 있습니다.

이해하기 쉽고 성능이 좋은 Play Framework를 좋아합니다. 원한다면 ORM 계층에 JPA와 Hibernate를 사용할 수도 있습니다.