java 프론트엔드 - "플레이"자바 웹 개발 프레임 워크와 어떤 경험?




공부순서 독학 (9)

난 그냥 다음과 같은 새로운 자바 웹 프레임 워크를 발견했습니다 : 재생

http://www.playframework.org/

http://www.playframework.org/documentation/1.0/home

그런 놀라운 기능 목록으로, 나는 전에 들어 본 적이 거의 없다는 것에 놀랐습니다 ...

자바 웹 개발과 같은 토지 약속의 소리 ...

아무도 그것을 시험해 보지 않았습니까? 그것으로 어떤 실제 경험? 그것을 공부할 가치가 있다고 생각합니까?


Answers

동료를 쫓아 낸 후 나는 그것을보고, 튜토리얼을 따라 갔고, 푹 빠져 들었다. 브라우저에서 즉각적인 피드백을 얻으면 IDE를 사용할 필요가 없습니다. 이클립스가 마음에 들지만, 직면하자. 몇 가지 추가 사항을 추가하면 간단한 텍스트 편집기만큼 안정적이지 못합니다. Mac에서 TextMate를 사용하면 브라우저의 오류 메시지를 클릭 할 수도 있습니다. 그러면 TextMate가 해당 행의 커서와 함께 팝업됩니다.

Play의 테스팅도 단 한 번의 버튼 조작으로 단위 테스트, 기능 테스트 및 Selenium 기반 테스트를 실행할 수 있습니다.

놀이는 여전히 작고 복잡하기 때문에 흥미 진진합니다. 그것은 개미를 사용하여 25 초 만에 빌드합니다. 아름다운 문서에 기여하는 것은 .textile 파일을 편집하고 모든 재생 응용 프로그램에서 문서를 다시로드하는 문제입니다.

그래서 스칼라를 사용하기 위해 튜토리얼을 번역하고 스칼라 지원에 가능한 한 좋은 곳을 추가해야 할 필요가있는 곳에 추가하는 방법을 모색했다.


나는 그것을 좋아한다, 나는 작은 프로젝트를 위해 그것을 사용하고있다. 그리고 지금까지 그것은 일을 위해 완전 해 보인다. 그러나, 내가 그리워하는 것이 한가지 있습니다. 서비스 / DAO / 모델 레이어 분리입니다. 설명서에는 Play의 목표 중 하나가 "Anemic 데이터 모델"을 피하는 것이 분명히 나와 있습니다. http://www.playframework.org/documentation/1.0.1/model

하지만 제 경험상 고전적인 Service / DAO / Model 레이어 분리는 응용 프로그램을 리팩터링해야하는 개발 시간을 대폭 줄여줍니다! Play를 사용하면 Play 관련 거래 관리 및 특성에 의존하는 정적 메소드가 붙어 있습니다 ...

그러나 개발 속도, 코드 청결성, 그리고 결국 ... 재미를위한 많은 것들이 있습니다!


나는 Play의 모습을 좋아하지만 시도하지는 않았습니다. 스캔을 통해 문서를 통해 눈에 띄는 한 가지 정적 메서드의 무거운 사용했다. 단위 테스트의 관점에서 볼 때, 이는 항상 일을 훨씬 어렵게 만든다. (mock을 생각하고있다.) 전형적인 Java 개발에서 OO-everywhere 접근법을 벗어난다. 어쩌면이게 중요한 부분 일지 모르지만, 그게 내게 조금 덜 흥분한 이유 일뿐입니다.


1 년이 지난 18 개의 작은 릴리스 이후 눈에 띄는 버그가 없으므로 Play! 1.2.4 학교 (생산자 :> 100 명의 교사,> 700 명의 학생, 행정 팀)에 대한 제작 "결석"인트라넷 신청. 클라이언트 측은 Adobe에서 FLEX 4.6으로 작성되었습니다 (매우 아름다운보기). 데이터는 AMF3 형식으로 보내고받습니다 (계피 모듈). 우리는 DB를 위해 JPA EclipseLink와 MySql을 기반으로하는 간단한 dao 계층을 사용합니다. 응용 프로그램은 Linux 가상 서버에 저장됩니다. 저는 단순함과 매우 생산적인 접근 방식으로 Play의 팬 개발자입니다.


저는 작은 프로젝트에서 Play를 사용하고 있으며 정확하게 말한 것 같습니다. 그러나 프레임 워크에 기본적으로 존재해야한다고 생각하는 기능은 하나 이상의 데이터 소스 (예 : 둘 이상의 데이터베이스 스키마 사용)로 작업하는 기능입니다. 이것이 지금까지 발견 한 유일한 기능입니다.

감사합니다, Uilian.


저는 Play를 시도해 봤지만 감동했습니다. 대부분의 프레임 워크보다 훨씬 단순한 유용한 개발 모델을 제공하는 것이 효과적입니다. ' 무엇보다도, .java 파일을 직접 파싱하는 '개발 모드'의 런타임 기능은 많은 가치가 있습니다. 빌드 스크립트를 실행하지 않고 브라우저에서 웹 페이지를 다시로드하거나 재배포를 기다리는 것만으로도 개발 속도가 상당합니다. 브라우저에 표시된 오류 메시지도 정말 좋습니다.

또 다른 사실은 전반적인 미학적 감각이었습니다. 튜토리얼 애플리케이션이 실제로 코드와 웹 페이지 디자인 모두 좋은 것처럼 보일 수도 있지만 전체 프레임 워크, API 및 문서로 확장됩니다.


현재 막대한 데이터 처리를하는 재생 프레임 워크를 사용하여 직장에서 웹 응용 프로그램을 작성합니다. 나는 놀이의 혼자만의 속도는 RoR이 제공 할 수있는 것보다 중요하고 더 중요하다고 말해야합니다. 게다가, 재생은 자바 기반의 프레임 워크이므로 멀티 스레딩은 쉽게 수행 할 수 있습니다. 다음은 Japid와 Netty 같은 자바 기반 모듈을 play와 함께 사용할 때 얻을 수있는 완전한 성능입니다. 성능 향상을 위해 끝없는 양의 조정이 가능한 것과 같습니다. 내 생각에 시도해야합니다.


Grails, Tapestry 4/5 및 Java / JSP / Spring / Hibernate를 사용했습니다.

나는 이것이 오랫동안 처음으로 올바른 방향으로 가고 있다고 생각한다. Grails는 정말 좋은 첫 걸음 이었지만 Play! 실제로 다리를 가질 수있는 것처럼 보입니다. 스칼라 지원은 1.1에서 나오고있다. 내 컨트롤러 / 도메인을 Clojure에 작성할 수있는 기회가 있다면 팔린다;)


SWT 는 그 자체로 꽤 낮은 수준이며, JNI를 통해 플랫폼의 기본 위젯을 사용합니다. 그것은 Swing 및 AWT와 전혀 관련이 없습니다. Eclipse IDEVuze BitTorrent 클라이언트 와 같은 Eclipse 기반의 모든 리치 클라이언트 애플리케이션은 SWT를 사용하여 빌드됩니다. 또한 Eclipse 플러그인을 개발하는 경우 일반적으로 SWT를 사용합니다.
필자는 거의 5 년 동안 Eclipse 기반 응용 프로그램과 플러그인을 개발해 왔기 때문에 명확하게 편향되었습니다. 그러나 SWT와 그 위에 구축 된 JFace UI 툴킷 을 다루는 데 많은 경험을 쌓았습니다. 나는 JFace가 매우 풍부하고 강력하다는 것을 알았습니다. 어떤 경우에는 SWT를 선택하는 주된 이유가 될 수도 있습니다. IDE, 테이블, 트리, 네이티브 컨트롤 등을 사용하는 한, 작업중인 UI를 아주 빨리 채찍질 할 수 있습니다. 물론 사용자 정의 컨트롤을 통합 할 수는 있지만 추가 작업이 필요합니다.





java frameworks playframework