[java] 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에 숨어 있습니다.
