나는이 질문이 조금 열려 있음을 알고 있지만 Java / Spring의 대안으로 Scala / Lift를 보았으며 Scala / Lift가 어떤 이점을 가지고 있는지 궁금합니다. 내 관점과 경험에서 Java Annotations와 Spring은 실제로 응용 프로그램에 필요한 코딩 양을 최소화합니다. 스칼라 / 리프트가 그 점을 개선합니까?
답변:
우리가 스칼라와 자바에서 똑같이 편안하다고 가정하고 스프링이나 리프트와 관련된 것을 제외하고는 (거대한) 언어 차이를 무시하십시오.
Spring and Lift는 성숙도와 목표 측면에서 거의 정반대입니다.
문장에서 Spring은 헤비급이고 Lift는 경량입니다. 충분한 의지와 자원을 사용하면 머리에 그것을 켤 수 있습니다,하지만 당신은 필요 많은 양의를.
두 프레임 워크로 작업 한 후 내 마음에 붙어있는 구체적인 차이점이 있습니다. 이것은 완전한 목록이 아니며, 어쨌든 컴파일 할 수 없습니다. 나에게 가장 흥미로 웠던 것 ...
철학보기
Lift는 스 니펫 / 액션 메소드에 일부 뷰 자료를 배치하도록 권장합니다. 스 니펫 코드는 특히 프로그래밍 방식으로 생성 된 양식 요소, <div>s, <p>s 등 으로 뿌려집니다 .
특히 Scala에는 언어 수준의 XML 모드가 내장되어 있기 때문에 강력하고 유용합니다. 중괄호에 변수 바인딩을 포함하여 Scala 메소드 내에 XML 인라인을 작성할 수 있습니다. 이는 매우 간단한 XML 서비스 또는 서비스 목업에 유쾌 할 수 있습니다. 템플릿이나 많은 수반하는 구성 없이도 하나의 아주 단순한 파일로 HTTP 응답 작업 모음을 모두 제거 할 수 있습니다. 단점은 복잡성입니다. 당신이 얼마나 멀리 가느냐에 따라, 관점과 논리 사이에 퍼지 문제가 퍼지거나 분리되지 않습니다.
대조적으로, 웹 애플리케이션에 Spring을 정기적으로 사용하면 뷰와 다른 모든 것을 강력하게 분리 할 수 있습니다. Spring이 여러 템플릿 엔진을 지원한다고 생각하지만 심각한 것은 JSP 만 사용했습니다. JSP로 리프트에서 영감을 얻은 "퍼지 MVC"디자인을하는 것은 광기 일 것입니다. 이것은 방금 읽고 이해하는 시간이 압도적 일 수있는 대규모 프로젝트에서 좋은 것입니다.
객체 관계형 매퍼 선택
Lift의 내장 ORM은 "매퍼"입니다. "레코드"라고하는 다른 대안이 있지만 여전히 프리 알파로 간주되는 것 같습니다. LiftWeb Book에는 Mapper와 JPA 사용에 대한 섹션이 있습니다.
리프트의 CRUDify 기능은 멋지고 맵퍼 (JPA는 아님)에서만 작동합니다.
물론 Spring은 표준 및 / 또는 성숙한 데이터베이스 기술을 광범위하게 지원합니다 . 실 용어는 "지지하다"입니다. 이론적으로 Scala에서 임의의 Java 코드를 호출 할 수 있으므로 Lift와 함께 모든 Java ORM을 사용할 수 있습니다. 그러나 Lift는 실제로 Mapper와 JPA 만 지원합니다. 또한 스칼라에서 사소한 Java 코드 작업은 현재처럼 원활하지 않습니다. Java ORM을 사용하면 Java 및 Scala 콜렉션을 모두 사용하거나 Java 컴포넌트 내외부에서 모든 콜렉션을 변환 할 수 있습니다.
구성
Lift 앱은 애플리케이션 전체의 "부팅"클래스를 통해 거의 완전히 구성됩니다. 즉, 구성은 스칼라 코드를 통해 수행됩니다. 이것은 간단한 구성을 가진 프로젝트에 적합하며 구성을 수행하는 사람이 편하게 편집 할 수있는 스칼라입니다.
스프링은 구성 측면에서 매우 유연합니다. 많은 conf 옵션은 XML 구성 또는 주석을 통해 구동 될 수 있습니다.
선적 서류 비치
Lift의 문서는 젊습니다. Spring의 문서는 꽤 성숙하다. 컨테스트가 없습니다.
Spring의 문서는 이미 잘 정리되어 있고 찾기 쉽기 때문에 Lift에서 찾은 문서를 검토하겠습니다. 기본적으로 Lift 문서에는 LiftWeb Book , API Docs , LiftWeb Google 그룹 및 " 시작하기 "의 4 가지 소스가 있습니다. 멋진 코드 예제 모음도 있지만 "문서"라고 부르지는 않습니다.
API 문서가 불완전합니다. LiftWeb Book은 나무에 출판되었지만 온라인에서도 무료로 이용할 수 있습니다. 결정적인 교훈적인 스타일이 때때로 나를 화나게했지만 실제로는 유용합니다. 튜토리얼이 길고 계약이 짧습니다. 스프링에는 적절한 매뉴얼이 있으며, 리프트에는 없습니다.
그러나 Lift에는 좋은 예가 있습니다. 리프트 코드와 예제 코드를 읽고 편하고 이미 스칼라를 잘 알고 있다면 상당히 짧은 순서로 문제를 해결할 수 있습니다.
두 프레임 워크 모두 매력적입니다. 하나를 선택하고 잘 수행 할 수있는 광범위한 앱이 있습니다.
Dan LaRocque의 답변에 강력하게 동의하지 않는다고 말해야합니다.
리프트는 모 놀리식이 아닙니다. 개별 요소로 구성됩니다. J / EE 요소를 무시하지 않고 JNDI, JTA, JPA 등을 지원합니다. 이러한 J / EE 요소를 강제로 사용하지 않는다는 사실은 Lift의 모듈 식 설계를 강력하게 나타냅니다.
위에서 말한 것처럼 Lift의 디자인 철학에 대해 이야기하겠습니다.
내가 쓴 웹 프레임 워크 선언을 내가 리프트를 쓰기 시작하기 전에. 내가 아는 다른 웹 프레임 워크의 경우보다 훨씬 큰 수준으로, Lift는 이러한 목표를 충족시킵니다.
핵심은 HTTP 요청 주위에 객체 래퍼를 배치하는 대신 HTTP 요청 / 응답주기를 추상화하는 것입니다. 실제로는 사용자가 수행 할 수있는 모든 작업 (양식 요소 제출, Ajax 수행 등)은 브라우저의 GUID와 서버의 기능으로 표시됩니다. GUID가 HTTP 요청의 일부로 제공되면 제공된 매개 변수와 함께 함수가 적용 (호출)됩니다. GUID는 예측하기 어렵고 세션에 따라 다르기 때문에 Spring을 포함한 대부분의 다른 웹 프레임 워크보다 Lift를 사용하면 재생 공격 및 많은 매개 변수 변조 공격이 훨씬 더 어렵습니다. 또한 개발자는 HTTP 요청 패킹 및 압축 풀기보다는 사용자 액션 및 사용자 액션과 관련된 비즈니스 로직에 초점을 맞추기 때문에 생산성이 향상됩니다.
ajaxButton("Accept", () => {request.accept.save;
SetHtml("acceptrejectspan", <span/>}) ++
ajaxButton("Reject", () => {request.reject.save;
SetHtml("acceptrejectspan", <span/>})
그렇게 간단합니다. 함수가 생성 될 때 friendRequest가 범위 내에 있기 때문에 함수가 범위를 닫습니다. 친구 요청의 기본 키를 노출하거나 다른 작업을 수행 할 필요가 없습니다. 버튼의 텍스트 만 정의하면됩니다. 현지화 또는 XHTML 템플릿에서 가져 오거나 현지화 된 템플릿에서 가져올 수 있음) 버튼을 누를 때 실행되는 기능. Lift는 GUID 할당, Ajax 호출 설정 (jQuery 또는 YUI를 통해 설정, 예를 들어 원하는 JavaScript 라이브러리를 추가 할 수 있음), 백오 프로 자동 재시도 수행, Ajax 요청 등을 큐잉하여 연결 부족을 방지합니다.
따라서 Lift와 Spring의 한 가지 큰 차이점은 기능과 관련된 Lift의 GUID 철학은 훨씬 더 나은 보안과 개발자의 생산성 향상이라는 이중 이점이 있다는 것입니다. GUID-> 함수 연결은 매우 내구성이 입증되었습니다 ... 동일한 구성은 일반 양식, 아약스, 혜성, 여러 페이지 마법사 등에서 작동합니다.
다음 핵심 핵심 요소는 가능한 한 오랫동안 높은 수준의 추상화를 유지하는 것입니다. 페이지 생성 측면에서 이는 페이지를 XHTML 요소로 작성하고 응답을 스트리밍하기 직전까지 페이지를 XHTML로 유지하는 것을 의미합니다. 크로스 사이트 스크립팅 오류, 페이지 구성 후 CSS 태그를 헤드로, 스크립트를 페이지 맨 아래로 이동하는 기능, 대상 브라우저를 기반으로 페이지를 다시 작성할 수있는 기능에 대한 이점이 있습니다. 입력측에서 URL을 다시 작성하여 형식이 안전한 방식으로 매개 변수 (쿼리 및 경로 매개 변수 모두)를 추출 할 수 있으며 요청주기 초기에 처리하기 위해 높은 수준의 보안 검사 데이터를 사용할 수 있습니다. 예를 들어, REST 요청의 서비스를 정의하는 방법은 다음과 같습니다.
serve {
case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
}
Scala의 내장 패턴 일치를 사용하여 수신 요청을 일치시키고 경로의 세 번째 부분을 추출하여 해당 값에 해당하는 사용자를 가져오고 액세스 제어 검사를 적용합니다 (현재 세션 또는 요청에 지정된 액세스 권한이 있습니까) 사용자 기록). 따라서 User 인스턴스가 응용 프로그램 논리에 도달하면 검사됩니다.
이 두 가지 핵심 요소를 통해 Lift는 보안 측면에서 엄청난 이점을 제공합니다. 기능에 방해가되지 않는 Lift의 보안 수준에 대한 아이디어를 제공하기 위해 Yahoo!의 보안을 담당 한 Rasmus Lerdorg 는 FourSquare (리프트 포스터 하위 사이트 중 하나)에 대해 다음과 같이 말합니다.
네 개의 별 @foursquare합니다 - 1 사이트 A의 내가 하나의 보안 문제 (I 찾을 수)하지 않았다에서 좋은 모습을 찍은 반면 - http://twitter.com/rasmus/status/5929904263을
당시 FourSquare는 한 명의 엔지니어 (@harryh가 슈퍼 천재가 아님)를 담당했으며 주된 트래픽은 주간 트래픽 배가에 대처하면서 FourSquare의 PHP 버전을 다시 작성하는 데 주력했습니다.
Lift의 보안 초점의 마지막 부분은 SiteMap입니다. 통합 된 액세스 제어, 사이트 탐색 및 메뉴 시스템입니다. 개발자는 스칼라 코드 (예 : If(User.loggedIn _)또는 If(User.superUser _))를 사용하여 각 페이지에 대한 액세스 제어 규칙을 정의 하며 이러한 액세스 제어 규칙은 페이지 렌더링이 시작되기 전에 적용됩니다. 이는 프로젝트 시작부터 시작되어 액세스 제어 규칙이 나머지 응용 프로그램과 통합되므로 URL이 보안 규칙을 업데이트 할 때 XML로 보안 규칙을 업데이트 할 필요가 없다는 점을 제외하면 Spring Security와 매우 유사합니다. 변경 또는 액세스 제어 변경을 계산하는 방법.
지금까지 Lift의 디자인 철학은 액세스 제어, OWASP 상위 10 가지 보안 취약점에 대한 내성, 훨씬 더 나은 Ajax 지원 및 Spring보다 훨씬 높은 개발자 생산성을 제공합니다.
그러나 Lift는 또한 모든 웹 프레임 워크에 대해 최고의 Comet 지원을 제공합니다. 이것이 Novell이 Pulse 제품 에 전원을 공급하기 위해 Lift를 선택한 이유 이며 Novell이 Lift에 대해 말한 내용은 다음과 같습니다.
Lift는 개발자가 큰 그림에 집중할 수 있도록하는 일종의 웹 프레임 워크입니다. 내장 된 Comet 지원과 같은 강력하고 표현적인 타이핑 및 고급 기능을 통해 배관 대신 혁신에 집중할 수 있습니다. Novell Pulse와 같은 풍부한 실시간 웹 애플리케이션을 구축하려면 표지 아래에 Lift 기능이있는 프레임 워크가 필요합니다.
따라서 Lift는 단순한 또 다른 MVC 프레임 워크가 아닙니다. 아주 잘 발달 된 핵심 설계 원칙을 가지고있는 프레임 워크입니다. 보안 및 개발자 생산성의 이중 이점을 제공하는 프레임 워크입니다. Lift는 계층으로 구축 된 프레임 워크로 개발자에게 필요에 따라 올바른 뷰 선택, 뷰 생성 선택, 지속성 선택 등을 제공합니다.
스칼라와 리프트는 개발자에게 XML의 멜란지, 주석 및 Spring을 구성하는 다른 관용구보다 훨씬 나은 경험을 제공합니다.
Spring MVC의 열렬한 팬이 아닌 최근 웹 프로젝트에 Lift를 사용하는 것을 강력히 조사했습니다. 최신 버전을 사용하지는 않았지만 이전 버전의 Spring MVC를 사용하면 웹 응용 프로그램을 실행하기 위해 많은 노력을 기울였습니다. Lift가 세션에 매우 의존적이며 올바르게 작동하려면 '고정 세션'이 필요할 때까지 Lift에서 거의 판매되었습니다. http://exploring.liftweb.net/master/index-9.html#sec:Session-Management 에서 발췌
표준 세션 복제 기술이있을 때까지“고정 세션”을 사용하여 응용 프로그램을 클러스터링 할 수 있습니다. 이는 HTTP 세션과 관련된 모든 요청이 동일한 클러스터 노드에서 처리되어야한다는 것을 의미합니다.
따라서 세션이 필요하면 사용자는 해당 노드에 고정되어야합니다. 이를 통해 지능적인로드 밸런싱이 필요하고 스케일링에 영향을 미치므로 Lift가 솔루션으로 사용할 수 없었습니다. 나는 http://www.playframework.org/ 를 선택 하게되었고 매우 기뻤습니다. 놀이는 지금까지 안정적이고 신뢰할 수 있으며 작업하기가 매우 쉽습니다.
겸손한 의견으로는 상상력이 중요합니다.
앱을 작성한다고 가정 해 봅시다. 괜찮은 개발자라면 이미 앱이 마음에 들어 있어야합니다. 다음 단계는 코드를 통해 어떻게 작동하는지 알아내는 것입니다. 그렇게하려면 상상 된 앱을 실제 앱으로 변환하는 함수를 통해 전달해야합니다. 그 기능은 프로그래밍 언어입니다. 그래서
Real app = programming language (imagined app)언어 선택이 중요합니다. 프레임 워크도 마찬가지입니다. 선택해야 할 것에 대해 조언 해 줄 똑똑한 사람들이 많이 있지만 궁극적으로 상상력을 가장 잘 표현하는 언어 / 프레임 워크는 선택해야합니다. 따라서 두 가지 모두로 프로토 타입을 만들고 선택하십시오.
나는 스칼라와 리프트를 천천히 배우고 사랑하고 있습니다.