Java/Spring에서 Scala/Lift를 사용하는 이유는 무엇입니까?

Java/Spring에서 Scala/Lift를 사용하는 이유는 무엇입니까?

닫았습니다. 이 질문은의견 기반의현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하시겠습니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트하십시오.

8년 전에 문을 닫았어요

이 질문을 개선하다

이 질문이 다소 미해결인 것은 알지만, Java/Spring의 대안으로 Scala/Lift를 검토하고 있습니다.Scala/Lift가 이 문제에 대해 갖는 진정한 이점은 무엇인지 궁금합니다.제 견해와 경험상 Java Annotations와 Spring은 애플리케이션에 대해 수행해야 하는 코딩 양을 최소화합니다.Scala/Lift는 그것을 개선합니까?

Dan LaRocke의 대답에 전적으로 반대합니다.

리프트는 일체형이 아닙니다.개별적인 요소로 구성되어 있습니다.J/EE 요소를 무시하지 않고 JNDI, JTA, JPA 등을 지원합니다.J/EE의 이러한 요소를 사용할 필요가 없다는 사실은 Lift의 모듈식 설계를 강하게 시사합니다.

• Lift의 견해는 "개발자가 결정하게 하라"는 것입니다.Lift는 뷰에서 논리 코드를 허용하지 않는 템플릿 메커니즘, Scala 코드 및 Scala의 XML 리터럴 실행을 기반으로 하는 뷰 메커니즘 및 Scalate를 기반으로 하는 뷰 메커니즘을 제공합니다.XML 템플릿메커니즘을 선택할 경우 비즈니스 로직에서 마크업이 어느 정도(있는 경우)에 속할지를 선택합니다.Lift의 XML 템플릿에서는 비즈니스 로직을 표현할 수 없기 때문에 Lift의 뷰 분리는 Spring이 제공하는 어떤 것보다도 강력합니다.
• Lift의 객체 ↔ 지속성 철학은 "개발자가 결정하게 하라"입니다.리프트에는 ActiveRecord 스타일의 객체 관계형 매퍼인 매퍼가 있습니다.작은 프로젝트에도 대응할 수 있습니다.서포트 JPA를 들어 올립니다.Lift는 관계형 데이터베이스, NoSQL 스토어, CouchDB 및 MongoDB에 대한 네이티브 지원을 지원하는 Record 추상화를 가지고 있습니다(리프트는 CouchDB 및 MongoDB에 대한 네이티브 지원을 포함하지만 어댑터 계층은 수백 줄의 코드이므로 Cassandra 또는 다른 것을 원하는 경우 많은 작업이 필요하지 않습니다).기본적으로 Lift the Web Framework는 오브젝트가 세션으로 구체화되는 방법에 의존하지 않습니다.또한 세션 및 요구 사이클은 요구/응답 사이클에 트랜잭션 훅을 삽입하는 것이 간단하도록 개방된다.
• Lift의 철학은 "서버 팀은 여러 언어가 아닌 하나의 언어를 알아야 한다"입니다.즉, 설정은 Scala 경유로 이루어집니다.즉, 유연한 구성 옵션을 작성하기 위해 Java 언어구조의 40%를 XML 구문에서 구현할 필요가 없었습니다.즉, 컴파일러가 설정 데이터를 체크하고 실행 시 이상한 XML 구문 분석이나 잘못된 데이터를 얻지 않도록 합니다.즉, 사용 중인 라이브러리에 따라 사용 중인 주석의 세부 정보를 이해하는 IDE가 없어도 됩니다.
• 네, Lift의 문서는 그 장점이 아닙니다.

이상, Lift의 디자인 철학에 대해 말씀드리겠습니다.

Lift를 쓰기 전에 Web Framework Manifesto를 작성했습니다.제가 아는 다른 어떤 웹 프레임워크보다 훨씬 더 많이, 그리고 Lift는 이러한 목표를 충족합니다.

코어에서의 리프트는 HTTP 요청 주위에 오브젝트래퍼를 배치하는 것이 아니라 HTTP 요청/응답 사이클을 추상화하려고 합니다.실제적인 수준에서는 사용자가 수행할 수 있는 대부분의 액션(폼 요소 제출, Ajax 실행 등)이 브라우저의 GUID와 서버상의 함수로 표현된다는 것을 의미합니다.GUID가 HTTP 요청의 일부로 제시되면 함수는 지정된 파라미터로 적용(호출)됩니다.GUID는 예측이 어렵고 세션에 따라 다르므로 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 경유), 백오프 자동 재시도 실행, Ajax 요청 큐잉 등에 의한 접속 고갈을 회피합니다.

Lift와 Spring의 큰 차이점은 기능과 관련된 Lift의 GUID 철학에 보안과 개발자 생산성이 크게 향상된다는 것입니다.GUID -> 기능 관련성은 매우 견고하다는 것이 증명되었습니다.일반 형태, Ajax, comet, 여러 페이지 마법사 등에 동일한 구성이 적용됩니다.

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)
  }

Scala의 내장 패턴 매칭을 사용하여 수신 요청을 대조하고 경로의 세 번째 부분을 추출하여 해당 값에 대응하는 사용자를 가져옵니다.또한 접근컨트롤 체크도 적용합니다(현재 세션 또는 요청에 지정된 사용자 레코드에 대한 접근 권한이 있는지 여부).따라서 사용자 인스턴스가 애플리케이션 로직에 도달할 때까지 검증됩니다.

이 두 가지 핵심 요소로 인해 Lift는 보안 측면에서 매우 유리합니다.기능에 방해가 되지 않는 Lift의 보안의 크기를 알기 위해 Yahoo!의 보안을 담당한 Rasmus Lerdog는 FourSquare(Lift 포스터-차일드 사이트 중 하나)에 대해 다음과 같이 말했다.

@foursquare에 별 4개 표시 - 오랜만에 자세히 살펴보니 보안상의 문제가 전혀 없었습니다.http://twitter.com/rasmus/status/5929904263

당시 FourSquare에는 코드 작업을 하는 엔지니어가 1명 있었다(@harryh가 슈퍼천재가 아닌 것은 아니다). 그의 주된 초점은 매주 트래픽이 두 배로 증가하는 것에 대처하면서 PHP 버전의 FourSquare를 다시 쓰는 것이었다.

Lift 보안의 마지막 부분은 SiteMap입니다.통합 액세스 제어, 사이트 탐색 및 메뉴 시스템입니다.개발자는 Scala 코드를 사용하여 각 페이지에 대한 액세스 제어 규칙을 정의합니다(예:If(User.loggedIn _)또는If(User.superUser _)페이지 렌더링을 시작하기 전에 이러한 접근컨트롤 규칙이 적용됩니다.이는 Spring Security와 매우 유사하지만 프로젝트 시작부터 기본 제공되며 액세스컨트롤 규칙은 나머지 애플리케이션과 통합되어 있기 때문에 URL이나 액세스컨트롤 계산 방법이 변경되었을 때 XML 보안 규칙을 갱신하는 프로세스가 필요하지 않습니다.

지금까지의 요점을 정리하면, Lift의 설계 이념은, Spring보다 액세스 제어 기능 강화, OWASP의 10대 시큐러티 취약성에 대한 내성, Ajax의 서포트, 개발자의 생산성 향상을 실현합니다.

그러나 Lift는 또한 주변 웹 프레임워크 중 최고의 Comet 지원을 제공합니다.그렇기 때문에 Novell은 Pulse 제품에 전원을 공급하기 위해 Lift를 선택했습니다.Novell은 Lift에 대해 다음과 같이 말합니다.

Lift는 개발자로서 큰 그림에 집중할 수 있는 웹 프레임워크입니다.내장된 Comet 지원과 같은 강력하고 표현력 있는 타이핑 및 고급 기능을 통해 배관 대신 혁신에 집중할 수 있습니다.Novell Pulse와 같은 풍부한 실시간 웹 애플리케이션을 구축하려면 Lift 기능을 갖춘 프레임워크가 필요합니다.

Lift는 단순한 미투 MVC 프레임워크가 아닙니다.이 프레임워크는 매우 잘 성숙된 몇 가지 핵심 설계 원칙을 가지고 있습니다.이 프레임워크는 보안과 개발자 생산성이라는 두 가지 이점을 제공합니다.Lift는 레이어에 내장된 프레임워크로 개발자에게 요구에 따라 적절한 선택을 제공합니다.뷰 생성 선택, 지속성 선택 등

Scala와 Lift는 개발자들에게 봄을 구성하는 XML, 주석 및 기타 관용구의 혼합보다 훨씬 더 나은 경험을 제공합니다.

Scala와 Java에 모두 익숙하고 스프링 또는 리프트와 관련된 경우를 제외하고는 (대규모) 언어의 차이를 무시한다고 가정해 봅시다.

스프링과 리프트는 성숙도와 목표 면에서 거의 정반대입니다.

• 봄은 리프트보다 약 5년 더 오래되었다.
• 리프트는 획일적이며 웹만을 대상으로 합니다.Spring은 모듈러형이며 웹 어플리케이션과 "일반" 어플리케이션 모두를 대상으로 합니다.
• Spring은 많은 Java EE 기능을 지원하지만 Lift는 이 기능을 무시합니다.

한 문장에서 스프링은 무겁고 리프트는 가볍다.충분한 결의와 자원을 가지고 있으면, 그것을 이용할 수 있지만, 그 양쪽 모두 많은 것이 필요합니다.

양쪽의 틀로 작업한 후, 마음에 남는 구체적인 차이점을 소개합니다.이것은 완전한 목록이 아닙니다.어차피 정리할 수 없습니다.내가 가장 흥미로워 보였던 건...

1. 철학 표시

   리프트는 일부 뷰 자료를 스니펫/액션 방법에 배치하는 것을 권장합니다.스니펫 코드에는 특히 프로그래밍 방식으로 생성된 폼 요소가 뿌려집니다.<div>s,<p>등

   특히 Scala에는 언어 수준의 XML 모드가 내장되어 있기 때문에 이것은 강력하고 유용합니다.괄호 안의 변수 바인딩을 포함하여 Scala 메서드 내에서 XML을 인라인으로 쓸 수 있습니다.이것은 매우 단순한 XML 서비스나 서비스의 목업에서 매우 편리합니다.템플릿이나 많은 어텐던트 설정 없이 HTTP 응답 액션 세트를 모두 훌륭하게 하나의 파일로 만들 수 있습니다.단점은 복잡성입니다.어디까지 가느냐에 따라 견해와 논리 사이에 애매한 문제가 있거나 분리되지 않는 경우가 있습니다.

   이와는 대조적으로 웹 앱에 Spring을 정기적으로 사용하면 보기와 다른 모든 것을 강력하게 분리할 수 있습니다.스프링은 여러 템플링 엔진을 지원하지만 JSP를 사용한 적은 없습니다.JSP와 함께 Lift에서 영감을 받은 "퍼지 MVC" 디자인을 하는 것은 미친 짓입니다.읽고 이해하는 데 시간이 많이 걸리는 대규모 프로젝트에서는 이 점이 좋습니다.

2. 오브젝트 관계형 매퍼 선택지

   리프트의 내장 ORM은 "매퍼"입니다."Record"라는 새로운 대안은 있지만 여전히 사전 알파로 간주됩니다.Lift Web Book에는 Mapper와 JPA를 모두 사용하는 섹션이 있습니다.

   Lift의 CRUDify 기능은 쿨하지만 Mapper에서만 작동합니다(JPA에서는 동작하지 않습니다).

   Of course, Spring supports a panoply of standard and/or mature database technologies. The operative word there is "supports". Theoretically, you can use any Java ORM with Lift, since you can call arbitrary Java code from Scala. But Lift only really supports Mapper and (to a much lesser extent) JPA. Also, working with nontrivial Java code in Scala is currently not as seamless as one might like; using a Java ORM, you will probably find yourself either using both Java and Scala collections everywhere or converting all collections in and out of the Java components.

3. Configuration

   Lift apps are configured pretty much entirely through a method an application-wide "Boot" class. In other words, the config is done through Scala code. This is perfect for projects with brief configurations, and when the person doing the configuring is comfortable editing Scala.

   Spring is pretty flexible in terms of configuration. Lots of conf options can be driven either through XML configuration or annotations.

4. Documentation

   Lift's documentation is young. Spring's docs are pretty mature. There's no contest.

   Since Spring's docs are already nicely organized and easy to find, I'll review the docs I found for Lift. There are basically 4 sources of Lift documentation: the LiftWeb Book, the API Docs, LiftWeb's Google group, and "Getting Started". There's also a nice suite of code examples, but I wouldn't call them "documentation" per se.

   The API docs are incomplete. The LiftWeb Book has been published on trees, but it's also freely available online. It is really useful, although its decidedly didactic style irritated me at times. It's a little long on tutorial and short on contract. Spring has a proper manual, which Lift lacks.

   But Lift does have a nice set of examples. If you're comfortable reading the Lift code and example code (and you know Scala well already), you can work things out in fairly short order.

Both frameworks are compelling. There's a broad range of apps where you can choose either and do well.

I would recommend you to check play framework, it has some very interesting ideas and supports development in Java and Scala

Just for fun. And for the sake of learning new programming approaches.

I strongly looked into using Lift for a recent web project, not being a big fan of Spring MVC. I have not used the latest versions, but the earlier versions of Spring MVC made you jump through a lot of hoops to get a web application running. I was almost sold on Lift until I saw that Lift can be very session dependent and would require 'sticky sessions' to work correctly. Excerpt from http://exploring.liftweb.net/master/index-9.html#sec:Session-Management

Until there is a standard session replication technology you can still cluster you application using “sticky session”. This meas that all requests pertaining to a HTTP session must be processed by the same cluster node

So once a Session is required, the user would have to be pin to that node. This creates the need for intelligent load balancing and affects scaling, which prevented Lift from being a solution in my case. I ended up selecting http://www.playframework.org/ and have been very pleased. Play has been stable and reliable so far and very easy to work with.

I didn't come to Lift and Scala from a Java background, so this isn't from personal experience, but I know that many Lift developers find Scala to be a much more concise and efficient language than Java.

Expanding your knowledge is always a worthwhile endeavor :) I just started learning Scala, it's affecting how I write normal Java and I can say it's been very beneficial so far.

I hate to completely throw your world for a loop. But you can you use Scala, Java, Lift, Spring in one application and have it not be a problem.

In my humble opinion, imagination is what matters.

Let's consider you want to write an app. If you're a decent developer, the app should already be build in your mind. The next step is to discover how it works through code. In order to do that, you need to pass the imagined app through a function that translates it to a real world app. That function is a programming language. So

Real app = programming language (imagined app)

So the language choice is important. So is the framework. There are a ton of smart people here that will advise you on what to chose, but ultimately, the language / framework that best translates your imagination should be your choice. So prototype with both and make your choice.

As for me, I'm slowly learning Scala and Lift and loving it.

But the main problem is we can't compare spring with lift. Lift is basically use as UI framework and Spring is use as DI framework.
If you are developing web app that does have that much of backend sure you can use lift.
but if your developing web app that have some series backend and you definelty need to goto spring.

ReferenceURL : https://stackoverflow.com/questions/2683914/why-would-i-use-scala-lift-over-java-spring