[SPRING] Scala / Lift over Java / Spring을 사용하는 이유는 무엇입니까? [닫은]

Scala / Lift over Java / Spring을 사용하는 이유는 무엇입니까? [닫은]

나는이 질문이 조금 열려 있다는 것을 알고 있지만, Java / Spring의 대안으로 Scala / Lift를 살펴 봤으며 Scala / Lift가 가지고있는 진정한 이점이 무엇인지 궁금합니다. 필자의 시각과 경험을 통해 Java Annotations와 Spring은 애플리케이션에 대해 수행해야하는 코딩 작업을 최소화합니다. 스칼라 / 리프트가 그 점을 개선합니까?

해결법

1. ==============================

   1.스칼라와 자바에서 우리가 똑같이 편안하다고 가정하고, Spring이나 Lift와 관련된 경우를 제외하고 (거대한) 언어 차이점을 무시하자.

   스칼라와 자바에서 우리가 똑같이 편안하다고 가정하고, Spring이나 Lift와 관련된 경우를 제외하고 (거대한) 언어 차이점을 무시하자.

   봄과 리프트는 성숙과 목표 측면에서 거의 정반대의 입장입니다.

   문장에서는, 봄은 중량급이고 상승은 경량이다. 충분한 결정과 자원으로 당신은 그 머리를 돌릴 수 있지만, 당신은 많은 것을 필요로 할 것입니다.

   두 가지 프레임 워크로 작업 한 후 내 마음 속에 고착 된 구체적인 차이점은 다음과 같습니다. 어쨌든 컴파일 할 수없는 철저한 목록은 아닙니다. 그냥 나에게 가장 흥미로 웠던 것 ...

   두 프레임 워크 모두 매력적입니다. 선택할 수 있고 잘 할 수있는 다양한 앱이 있습니다.

2. ==============================

   2.나는 Dan LaRocque의 대답에 동의하지 않는다고 말하고 싶다.

   나는 Dan LaRocque의 대답에 동의하지 않는다고 말하고 싶다.

   리프트는 단일체가 아닙니다. 이는 개별 요소로 구성됩니다. J / EE 요소를 무시하지 않고 JNDI, JTA, JPA 등을 지원합니다. J / EE의 이러한 요소를 사용하지 않아도된다는 사실은 Lift의 모듈 식 설계를 강력하게 나타냅니다.

   위와 같이 말하면서 Lift의 디자인 철학에 대해 이야기 해 보겠습니다.

   나는 Lift를 쓰기 시작하기 전에 Web Framework Manifesto를 썼다. 내가 아는 다른 웹 프레임 워크의 경우보다 훨씬 훌륭한 수준으로 Lift는 이러한 목표를 충족시킵니다.

   리치는 HTTP 요청에 객체 래퍼를 배치하지 않고 HTTP 요청 / 응답주기를 추상화하려고합니다. 실용적인 수준에서 이것은 사용자가 취할 수있는 대부분의 동작 (폼 요소 제출, Ajax 수행 등)은 브라우저의 GUID와 서버의 기능으로 표현됩니다. GUID가 HTTP 요청의 일부로 제공되면 함수는 제공된 매개 변수와 함께 적용 (호출)됩니다. GUID는 예측하기 어렵고 세션에 따라 다르기 때문에 Lift에서는 Spring을 비롯한 대부분의 다른 웹 프레임 워크보다 재생 공격과 많은 매개 변수 변조 공격이 훨씬 어렵습니다. 또한 개발자는 HTTP 요청의 압축 및 압축 풀기보다는 사용자 작업 및 사용자 작업과 관련된 비즈니스 논리에 중점을 둠으로써 개발자가 더 생산적이라는 것을 의미합니다. 예를 들어 FourSquare 친구 요청을 수락 또는 거부하는 코드는 다음과 같습니다.

   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의 큰 차이점 중 하나는 기능과 관련된 GUID의 철학이 훨씬 향상된 보안과 개발자 생산성 향상이라는 두 가지 이점이 있다는 것입니다. GUID -> Function 연관성은 매우 내구성이 입증되었습니다. 일반 양식, 아약스, 혜성, 다중 페이지 마법사 등에 대해서도 동일한 구문이 적용됩니다.

   Lift의 다음 핵심 부분은 가능한 한 오랫동안 높은 수준의 추상화를 유지하는 것입니다. 페이지 생성 측면에서, 이는 페이지를 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)
     }
   

   스칼라의 내장 패턴 일치를 사용하여 들어오는 요청을 일치시키고 경로의 세 번째 부분을 추출하여 해당 값에 해당하는 사용자를 얻으며 액세스 제어 검사를 적용합니다 (현재 세션이나 요청에 지정된 액세스 권한이 있습니까? 사용자 레코드). 따라서 사용자 인스턴스가 응용 프로그램 논리에 부딪 힐 때까지는이를 심사합니다.

   이 두 가지 핵심 요소를 통해 Lift는 보안 측면에서 엄청난 이점을 제공합니다. 기능에 방해가되지 않는 리프트의 보안 수준에 대한 아이디어를 얻기 위해 Yahoo!의 보안을 담당 한 Rasmus Lerdorg FourSquare (리프트 포스터 - 아동 사이트 중 하나)에 대해 이렇게 말했습니다.

   당시 FourSquare는 한 엔지니어가 코드 작업을하고 있었고 (@harryh는 최고 천재가 아니 었습니다) 주간 트래픽을 두 배로 늘리는 한편 Four Focus의 PHP 버전을 다시 작성했습니다.

   Lift의 보안 초점의 마지막 부분은 SiteMap입니다. 통합 액세스 제어, 사이트 탐색 및 메뉴 시스템입니다. 개발자는 페이지 렌더링이 시작되기 전에 Scala 코드 (예 : If (User.loggedIn _) 또는 If (User.superUser _))와 해당 액세스 제어 규칙이 적용된 각 페이지에 대한 액세스 제어 규칙을 정의합니다. 이는 Spring Security와 매우 흡사합니다. 단, 프로젝트 초기부터 구워지고 액세스 제어 규칙이 나머지 응용 프로그램과 통합되므로 URL의 URL이 변경 될 때 XML의 보안 규칙을 업데이트하는 프로세스가 필요 없습니다. 변경하거나 액세스 제어를 변경하는 메소드가 변경됩니다.

   지금까지 요약하면, Lift의 디자인 철학은 액세스 제어, OWASP 10 대 보안 취약점에 대한 저항, Ajax 지원 향상, 개발자 생산성 향상 등 Spring의 이점을 누릴 수있는 이점을 제공합니다.

   그러나 Lift는 또한 모든 웹 프레임 워크에 대해 Comet이 지원하는 최상의 기능을 제공합니다. 그래서 Novell은 Pulse 제품에 전원을 공급하기 위해 Lift를 선택했으며 Novell은 Lift에 관해 다음과 같이 말합니다.

   그래서 Lift는 MVC 프레임 워크가 아닙니다. 이 프레임 워크는 그 뒤에 핵심 디자인 원리가있어 성숙한 프레임 워크입니다. 이는 보안과 개발자 생산성이라는 두 가지 이점을 제공하는 프레임 워크입니다. Lift는 레이어로 제작 된 프레임 워크이며 개발자가 필요에 따라 올바른 선택을 제공합니다.보기 생성, 지속성 선택 등을위한 선택 사항입니다.

   스칼라와 리프트는 개발자들에게 XML, 주석, 그리고 다른 봄말을 구성하는 관용구보다 더 나은 경험을 제공합니다.

3. ==============================

   3.내가 플레이 프레임 워크를 확인하는 것이 좋습니다, 그것은 매우 흥미로운 아이디어를 가지고 있으며 자바와 스칼라에서 개발을 지원합니다.

   내가 플레이 프레임 워크를 확인하는 것이 좋습니다, 그것은 매우 흥미로운 아이디어를 가지고 있으며 자바와 스칼라에서 개발을 지원합니다.

4. ==============================

   4.재미로. 그리고 새로운 프로그래밍 방식을 배우기 위해서.

   재미로. 그리고 새로운 프로그래밍 방식을 배우기 위해서.

5. ==============================

   5.필자는 최근 웹 프로젝트에서 Lift를 사용하는 것을 강하게 바라 보았지만 Spring MVC의 큰 팬이 아니었다. 필자는 최신 버전을 사용하지 않았지만 이전 버전의 스프링 MVC를 사용하면 웹 애플리케이션을 실행하기 위해 많은 노력을해야했습니다. 리프트가 세션에 매우 의존적 일 수 있고 제대로 작동하려면 '끈적 세션'이 필요하다는 것을 알기 전까지 리프트에서 거의 팔렸습니다. http://exploring.liftweb.net/master/index-9.html#sec:Session-Management에서 발췌 한 내용

   필자는 최근 웹 프로젝트에서 Lift를 사용하는 것을 강하게 바라 보았지만 Spring MVC의 큰 팬이 아니었다. 필자는 최신 버전을 사용하지 않았지만 이전 버전의 스프링 MVC를 사용하면 웹 애플리케이션을 실행하기 위해 많은 노력을해야했습니다. 리프트가 세션에 매우 의존적 일 수 있고 제대로 작동하려면 '끈적 세션'이 필요하다는 것을 알기 전까지 리프트에서 거의 팔렸습니다. http://exploring.liftweb.net/master/index-9.html#sec:Session-Management에서 발췌 한 내용

   따라서 세션이 필요하면 사용자는 해당 노드에 핀을 꽂아야합니다. 이는 지능형로드 밸런싱에 대한 필요성을 만들어 내고 스케일링에 영향을 미치기 때문에 Lift는 필자의 경우 솔루션이되지 못합니다. 나는 http://www.playframework.org/를 선택하고 매우 기뻤습니다. Play는 지금까지 안정적이고 신뢰할 수 있으며 작업하기가 쉽습니다.

6. ==============================

   6.필자는 자바 환경에서 리프트와 스칼라로 가지 않았기 때문에 개인적인 경험에서 나온 것이 아니지만 많은 리프트 개발자가 스칼라가 자바보다 훨씬 간결하고 효율적인 언어라는 것을 알고 있습니다.

   필자는 자바 환경에서 리프트와 스칼라로 가지 않았기 때문에 개인적인 경험에서 나온 것이 아니지만 많은 리프트 개발자가 스칼라가 자바보다 훨씬 간결하고 효율적인 언어라는 것을 알고 있습니다.

7. ==============================

   7.지식 확장은 항상 가치있는 일입니다 :) 스칼라를 배우기 시작했습니다. 스칼라를 배우기 시작한 것은 정상적인 자바를 작성하는 방법에 영향을 미치고 있으며 지금까지는 매우 유익했습니다.

   지식 확장은 항상 가치있는 일입니다 :) 스칼라를 배우기 시작했습니다. 스칼라를 배우기 시작한 것은 정상적인 자바를 작성하는 방법에 영향을 미치고 있으며 지금까지는 매우 유익했습니다.

8. ==============================

   8.나는 당신의 세계를 완전히 던지기를 완전히 싫어한다. 그러나 Scala, Java, Lift, Spring을 하나의 응용 프로그램에서 사용할 수 있으며 문제가되지 않도록 할 수 있습니다.

   나는 당신의 세계를 완전히 던지기를 완전히 싫어한다. 그러나 Scala, Java, Lift, Spring을 하나의 응용 프로그램에서 사용할 수 있으며 문제가되지 않도록 할 수 있습니다.

9. ==============================

   9.나의 겸손한 의견에서, 상상력은 중요합니다.

   나의 겸손한 의견에서, 상상력은 중요합니다.

   앱을 작성하려고한다고 가정 해 보겠습니다. 당신이 괜찮은 개발자라면, 앱은 이미 당신의 마음 속에 구축되어 있어야합니다. 다음 단계는 코드를 통해 작동하는 방식을 발견하는 것입니다. 그렇게하기 위해서는 실제 앱으로 변환하는 기능을 통해 상상 된 앱을 전달해야합니다. 이 함수는 프로그래밍 언어입니다. 그래서

   Real app = programming language (imagined app)
   

   따라서 언어 선택이 중요합니다. 프레임 워크도 그렇습니다. 여기에는 현명한 사람들이 엄선되어 무엇을 선택할지 조언 해줄 것이지만 궁극적으로 상상력을 가장 잘 번역 할 수있는 언어 / 프레임 워크를 선택해야합니다. 두 가지로 프로토 타입을 작성하고 원하는대로 선택하십시오.

   나로서는 천천히 스칼라와 리프트를 배우며 사랑해.

10. ==============================

    10.그러나 주된 문제는 우리는 봄을 양력과 비교할 수 없다는 것입니다. 리프트는 기본적으로 UI 프레임 워크로 사용되고 스프링은 DI 프레임 워크로 사용됩니다. 백엔드가 많이있는 웹 응용 프로그램을 개발중인 경우 리프트를 사용할 수 있습니다. 그러나 몇 가지 시리즈 백엔드가있는 개발중인 웹 응용 프로그램과 당신이 definitety spring으로 이동할 필요가 있다면.

    그러나 주된 문제는 우리는 봄을 양력과 비교할 수 없다는 것입니다. 리프트는 기본적으로 UI 프레임 워크로 사용되고 스프링은 DI 프레임 워크로 사용됩니다. 백엔드가 많이있는 웹 응용 프로그램을 개발중인 경우 리프트를 사용할 수 있습니다. 그러나 몇 가지 시리즈 백엔드가있는 개발중인 웹 응용 프로그램과 당신이 definitety spring으로 이동할 필요가 있다면.

from https://stackoverflow.com/questions/2683914/why-would-i-use-scala-lift-over-java-spring by cc-by-sa and MIT license