: 기능의 이러한 놀라운 목록"Play"Java 웹 개발 프레임 워크에 대한 경험이 있습니까?
http://www.playframework.org/documentation/1.0/home
플레이, 내가 들어하지 않은 꽤 많이 놀랐어요 그 전에 ...
는
아무도 그것을 시도했다 ... 땅 약속 자바 웹 개발 같은데? 그것으로 어떤 실제 경험? 그것을 공부할 가치가 있다고 생각합니까?나는 Play가 Grails보다 뛰어나다는 것을 Jason과 동의합니다. 내 벨트 아래에서 네 개의 Grails 프로젝트 (두 개의 Tapestry 프로젝트와 Wicket 프로젝트가 선행 된)를 통해 나는 Play를 진지하게 바라보고있다.
Grails에 대해 멋진 생각 중 하나는 "모든 것이 멋져요"입니다. 즉 Groovy를 사용하여 도메인, 컨트롤러, 서비스, 페이지 템플릿 (GSP), 태그 라이브러리, HORM (Hibernate API), 유닛 테스트 (GUnit) 및 스크립트 작성 (HTML 및 CSS 제외)을 작성합니다. GANT). Groovy에서 쉘 스크립트를 작성할 수도 있습니다. 따라서 단일 언어를 사용하여 응용 프로그램의 모든 측면을 다시 코딩 할 수 있다는 것은 C++ 또는 Delphi와 같은 단일 언어로 데스크톱 응용 프로그램을 작성한 시절로 돌아가서 오랜 기간 만료 된 단순화처럼 보였습니다. 그러나, 나는 하나의 크기가 여기에 모두 들어 맞지 않는다는 것을 배웠다.
하나의 경우, Groovy에 대한 IDE 지원은 좋지 않습니다. IntelliJ는 최고의 일을하지만, Groovy가 역동적이기 때문에 지금까지만 갈 수 있습니다. 리팩토링 도구는 모든 것을 포착 할 수는 없으므로 100 % 신뢰할 수는 없습니다. 즉, 단위 테스트에 특히주의해야합니다. 여기에도 Grails는 런타임시 발생하는 동적 "마법"에 너무 많이 의존하기 때문에 Grails의 단위 테스트는 광범위한 모의 레이어를 사용하여 에뮬레이션하고 모의 레이어를 기발하게 사용해야합니다. 세 번째 문제는 작성중인 Groovy 코드의 대부분이 실제로 도메인 특정 언어 (DSL) 코드라는 것입니다. 길게 이야기하자면, DSL은 그루비 (Groovy)와 많은 문법 (syntax)이 선택적이라는 사실을 이용하여 짧은 핸드의 Groovy입니다. Grails는 다양한 구성, URL 매핑 등에 대해 서로 다른 DSL을 사용하며 일관성이 없습니다. 예를 들어, log4j 설정을 지정하는 방법은 데이터 소스를 지정하는 방법처럼 보이지 않으며 Groovy의 기반이되는 순수 Java와 비슷하지도 않습니다. 그래서, "모든것이 멋져요"라는 약속은 어쨌든 붕괴됩니다.
그렇다면 Play 팀이 어디에서 왔는지 알 수 있습니다.
도메인, 컨트롤러, 서비스 및 JUnits의 일반 Java로 돌아갑니다.강력한 타이핑은 IDE가 인텔리 센스, 코드 네비게이션, 리팩토링 등을 통해 안정적으로 도움을받을 수 있음을 의미합니다 (따라서 Eclipse에 만족하면 IntelliJ를 지불 할 필요가 없습니다.) 더 자세한 코드를 작성하여 강력한 도구 지원을 되찾아 지금 당장 나에게 좋은 거래 인 것 같습니다. 우리가 볼거야.
나는 여전히 페이지 템플릿에서 Groovy를 사용하는 것을 좋아한다. 그래도 내가 템플릿보다 더 많은 코드를 넣을 수도 있습니다.
나는 JPA에 대한 경험이 없지만 GORM이 나를 위해하는 일에 매우 가깝기 때문에 멋지다.
Grails의 Spring IOC 지원은 완전히 투명하지만 Play의 지원은 최소화되어 있습니다. 그러나 IOC은 너무 많이 사용되었다고 생각합니다. 드물게 Spring XML 매핑을 코드에 넣고 싶습니다. 정말 필요합니다. (공개 질문 중 하나는 JPA가 Grails처럼 Spring을 필요로하지 않는 트랜잭션 지원이 있다고 가정한다는 것입니다.)
나는 결코 Python을 좋아하지 않았습니다. 그래서 나는 Play가 빌드 스크립트를 위해 Python을 사용한다는 것을 읽을 때 마음이 편찮습니다. Grails의 GANT 스크립트가 꽤 느리게 실행된다는 것에 동의합니다. 게다가 GANT가 XML ANT에 비해 엄청난 발전 이었지만 ANT 개념에 대한 귀하의 머리를 감싸는 것은 여전히 어렵습니다. Grails GANT 스크립트는 꽤 복잡합니다. 그래서 나는 열린 마음으로 그것에 갈 것입니다.
재생 "응용 프로그램 모듈"모델은 Grails의 "플러그인"모델처럼 들리므로 멋진 방법입니다.
저는 지금까지 읽은 Play 설명서에 깊은 인상을 받았습니다. 나는 거대한 숫자의 질문이 있었지만 그 중 절반은 배트에서 바로 대답했다.
나는 깊은 다이빙으로 나중에 다시보고 있습니다
Grails, Tapestry 4/5 및 Java/JSP/Spring/Hibernate를 사용했습니다.
저는 이것이 오랫동안 처음으로 올바른 방향으로 가고 있다고 생각합니다. Grails는 정말 좋은 첫 걸음 이었지만 Play! 실제로 다리를 가질 수있는 것처럼 보입니다. 스칼라 지원은 1.1에서 나오고있다. Clojure에서 콘트롤러/도메인을 작성할 수있는 기회가 있다면 팔린다;)
그루비를 줄곧 사용하는 것이 가능한가 궁금합니다 ... 나는 그렇게 생각합니다 ... 어쨌든, 스칼라에 총을 줄 가치가 있다고 생각합니다. ... – opensas
나는 Play의 모습을 좋아하지만 시도하지는 않았다. 스캔을 통해 문서를 통해 눈에 띄는 한 가지 정적 메서드의 무거운 사용했다. 단위 테스트의 관점에서 볼 때, 이는 항상 일을 훨씬 어렵게 만든다. (mock을 생각하고있다.) 전형적인 Java 개발에서 OO-everywhere 접근법을 벗어난다. 어쩌면이게 중요한 부분 일지 모르지만, 조금 덜 열정적 인 이유 일뿐입니다.
저는 그들의 주장이 컨트롤러가 단지 행동이라고 생각합니다. 함수 라이브러리와 같은 데이터가 전혀 없으므로 실제로는 객체가 아닙니다 ...하지만 어쨌든 나는 조롱과 관련하여 요점을 보았습니다. – opensas
나는 플레이를 시도하고 나는 감동 :. 그것은 유용한 개발 모델을 전달하는 훌륭한 일을 수행하는 훨씬 간단하다 대부분의 프레임 워크보다. 무엇보다도, .java 파일을 직접 파싱하는 '개발 모드'의 런타임 기능은 많은 가치가 있습니다. 빌드 스크립트를 실행하지 않고 브라우저에서 웹 페이지를 다시로드하거나 재배포를 기다리는 것만으로도 개발 속도가 상당합니다. 브라우저에 표시된 오류 메시지도 정말 좋습니다.
나를 감동 시켰던 또 다른 사실은 전반적인 미학이었습니다. 코드 및 웹 페이지 디자인 모두에서 튜토리얼 응용 프로그램이 실제로 좋아 보이는 것은 아마도 작은 것이지만, 전체 프레임 워크, API 에까지 확장됩니다. 문서로.
나는 주제에 대해 더 많이 썼다 : http://www.lunatech-research.com/archives/2010/03/15/play-framework-usability –
+1 "전반적인 미학적"을 언급했다. Scala의 +1 – fastcodejava
나는 동료를 구걸하고 나서 그것을 보았고 튜토리얼을 따라 갔다. 브라우저에서 즉각적인 피드백을 얻으면 IDE를 사용할 필요가 없습니다. 이클립스가 마음에 들지만, 직면하자. 몇 가지 추가 사항을 추가하면 간단한 텍스트 편집기만큼 안정적이지 못합니다. Mac에서 TextMate를 사용하면 브라우저의 오류 메시지를 클릭 할 수도 있습니다. 그러면 TextMate가 해당 행의 커서와 함께 팝업됩니다.
Play 테스트는 단 한 번의 버튼 조작으로 단위 테스트, 기능 테스트 및 Selenium 기반 테스트를 실행합니다.
아직 작고 복잡하지 않기 때문에 플레이가 흥미 롭습니다. 그것은 개미를 사용하여 25 초 만에 빌드합니다. 아름다운 문서에 기여하는 것은 .textile 파일을 편집하고 모든 재생 응용 프로그램에서 문서를 다시로드하는 문제입니다.
그래서 Scala를 사용하기 위해 튜토리얼을 번역하는 방법에 대해 알아 보았습니다. 스칼라 지원에 가능한 한 좋은 곳을 추가해야했습니다.
+1. 실제로 생산성을 향상시킵니다. – Magnus
저는 작은 프로젝트에서 Play를 사용하고 있으며 정확하게 말한 것 같습니다. 그러나 프레임 워크에 기본적으로 제공되어야한다고 생각하는 기능은 하나 이상의 데이터 소스 (예 : 둘 이상의 데이터베이스 스키마 사용)로 작업 할 수있는 기능입니다. 이것이 지금까지 발견 한 유일한 기능입니다.
감사합니다. Uilian.
그건 초기 Django에서도 문제가되었지만 프레임 워크가 성숙함에 따라 수정 될 것이라고 확신합니다. 그것은 주요 불만이 될 것입니다. –
한 번에 둘 이상의 데이터베이스를 사용한다는 의미입니까? – rogerdpack
참고로 여러 데이터베이스를 허용하는 재생 모듈이 있습니다. 이것은 아마 대답 당시 사실이 아니었지만, 이후 변경되었습니다. – Codemwnci
저는 작은 프로젝트에이 프로젝트를 사용하고 있으며 지금까지는 완벽하게 작동합니다. 그러나 내가 놓친 부분이 하나있다. Service/DAO/Model layers separation! 문서는 명확하게, 재생의 목표 중 하나는 "빈혈 데이터 모델"을 방지하는 것입니다 말한다 : http://www.playframework.org/documentation/1.0.1/model
하지만 내 경험에 고전 서비스/DAO/모델 층 분리가 개발 시간의 톤 응용 프로그램이 필요로 저장 리팩토링 되라! Play를 사용하면 Play 관련 거래 관리 및 특성에 의존하는 정적 메소드가 붙어 있습니다. ...
그러나 개발 속도, 코드 청결성, 그리고 결국에는 재미 있습니다!
현재 막대한 데이터 처리를 수행하는 재생 프레임 워크를 사용하여 직장에서 웹 응용 프로그램을 작성합니다. 나는 놀이의 혼자만의 속도는 RoR이 제공 할 수있는 것보다 중요하고 더 중요하다고 말해야합니다. 게다가, 재생은 자바 기반의 프레임 워크이므로 멀티 스레딩은 쉽게 수행 할 수 있습니다. 다음은 Japid와 Netty 같은 자바 기반 모듈을 play와 함께 사용할 때 얻을 수있는 완전한 성능입니다. 성능 향상을 위해 끝없는 양의 조정이 가능한 것과 같습니다. 내 생각에 시도해야합니다.
18 년 동안 출시 된 이후 1 년이 지나면 버그가 없으므로 Play! 1.2.4 학교 (생산자 :> 100 명의 교사,> 700 명의 학생, 행정 팀)에 대한 제작 "결석"인트라넷 신청. 클라이언트 측은 Adobe에서 FLEX 4.6으로 작성되었습니다 (매우 아름다운보기). 데이터는 AMF3 형식으로 보내고받습니다 (계피 모듈). 우리는 DB를 위해 JPA EclipseLink와 MySql을 기반으로하는 간단한 dao 계층을 사용합니다. 응용 프로그램은 Linux 가상 서버에 저장됩니다. 저는 단순함과 매우 생산적인 접근 방식으로 Play의 팬 개발자입니다.
이 응용 프로그램은 이제 Windows 서버에서 2.2.3으로 재생됩니다 (IT 관리의 요청). – jcstritt
나에게 아직 다른 응용 프로그램 프레임 워크처럼 보입니다. – skaffman