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

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

---

나는이 질문이 조금 열려 있음을 알고 있지만 Java / Spring의 대안으로 Scala / Lift를보고 있으며 Scala / Lift가 그에 비해 실제로 어떤 이점이 있는지 궁금합니다. 내 관점과 경험에서 Java Annotations와 Spring은 실제로 응용 프로그램에 필요한 코딩 양을 최소화합니다. 스칼라 / 리프트가 그 점을 개선합니까?

---

우리가 스칼라와 자바에서 똑같이 편안하다고 가정하고 스프링이나 리프트와 관련된 것을 제외하고는 (거대한) 언어 차이를 무시하십시오.

Spring and Lift는 성숙도와 목표 측면에서 거의 정반대입니다.

• 봄은 리프트보다 약 5 살이 깁니다.
• 리프트는 모 놀리 식이며 웹만 대상으로합니다. Spring은 모듈 식이며 웹 및 "일반"앱을 모두 대상으로합니다.
• Spring은 다양한 Java EE 기능을 지원합니다. 리프트는 그 물건을 무시합니다

문장에서 Spring은 헤비급이고 Lift는 경량입니다. 충분한 의지와 자원을 사용하면 머리에 그것을 켤 수 있습니다,하지만 당신은 필요 많은 양의를.

두 프레임 워크로 작업 한 후 내 마음에 붙어있는 구체적인 차이점이 있습니다. 이것은 완전한 목록이 아니며, 어쨌든 컴파일 할 수 없습니다. 나에게 가장 흥미로 웠던 것 ...

1. 철학보기

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

   특히 Scala에는 언어 수준의 XML 모드가 내장되어 있기 때문에 강력하고 유용합니다. 중괄호에 변수 바인딩을 포함하여 Scala 메소드 내에 XML 인라인을 작성할 수 있습니다. 이는 매우 간단한 XML 서비스 또는 서비스 목업에 유쾌 할 수 있습니다. 템플릿이나 많은 수반하는 구성 없이도 하나의 아주 단순한 파일로 HTTP 응답 작업 모음을 모두 제거 할 수 있습니다. 단점은 복잡성입니다. 당신이 얼마나 멀리 가느냐에 따라, 관점과 논리 사이에 퍼지 우려가 분리되거나 분리되지 않습니다.

   대조적으로, 웹 애플리케이션에 Spring을 정기적으로 사용하면 뷰와 다른 모든 것을 강력하게 분리 할 수 ​​있습니다. Spring이 여러 템플릿 엔진을 지원한다고 생각하지만 심각한 것은 JSP 만 사용했습니다. JSP로 리프트에서 영감을 얻은 "퍼지 MVC"디자인을하는 것은 광기 일 것입니다. 이것은 단지 읽고 이해하는 시간이 압도적 일 수있는 대규모 프로젝트에서 좋은 것입니다.

2. 객체 관계형 매퍼 선택

   리프트의 내장 ORM은 "매퍼"입니다. "레코드"라고하는 다른 대안이 있지만 여전히 프리 알파로 간주되는 것 같습니다. LiftWeb Book에는 Mapper와 JPA 사용에 대한 섹션이 있습니다.

   리프트의 CRUDify 기능은 멋지고 맵퍼 (JPA는 아님)에서만 작동합니다.

   물론 Spring은 표준 및 / 또는 성숙한 데이터베이스 기술을 광범위하게 지원합니다 . 실 용어는 "지지하다"입니다. 이론적으로 Scala에서 임의의 Java 코드를 호출 할 수 있으므로 Lift와 함께 모든 Java ORM을 사용할 수 있습니다. 그러나 Lift는 실제로 Mapper와 JPA 만 지원합니다. 또한 스칼라에서 사소한 Java 코드 작업은 현재처럼 원활하지 않습니다. Java ORM을 사용하면 Java 및 Scala 콜렉션을 모두 사용하거나 Java 컴포넌트 내외부에서 모든 콜렉션을 변환 할 수 있습니다.

3. 구성

   Lift 앱은 애플리케이션 전체의 "부트"클래스를 통해 거의 완전히 구성됩니다. 즉, 구성은 스칼라 코드를 통해 수행됩니다. 이것은 간단한 구성을 가진 프로젝트에 적합하며 구성을 수행하는 사람이 편하게 편집 할 수있는 스칼라입니다.

   스프링은 구성 측면에서 매우 유연합니다. 많은 conf 옵션은 XML 구성 또는 주석을 통해 구동 될 수 있습니다.

4. 선적 서류 비치

   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는 뷰에서 논리 코드를 허용하지 않는 템플릿 메커니즘, 스칼라 코드 및 Scala의 XML 리터럴 실행을 기반으로하는 뷰 메커니즘 및 Scalate 기반 뷰 메커니즘을 제공 합니다. XML 템플릿 메커니즘을 선택하면 비즈니스 로직에 마크 업이 어느 정도 존재하는지 선택합니다. Lift의 XML 템플릿으로 비즈니스 로직을 표현할 수 없으므로 Lift의 뷰 분리는 Spring이 제공하는 것보다 강력합니다.
• Lift 's Object ↔ 지속성 철학은 "개발자가 결정하게한다". Lift에는 ActiveRecord 스타일 객체 관계형 매퍼 인 Mapper가 있습니다. 소규모 프로젝트를 위해 작업이 완료됩니다. 지원 JPA를 드십시오. Lift에는 관계형 데이터베이스 내외부, NoSQL 저장소 내외부로 객체 셔틀을 지원하는 레코드 추상화 기능이 있습니다 (Lift에는 CouchDB 및 MongoDB에 대한 기본 지원이 포함되지만 어댑터 계층은 수백 줄의 코드이므로 Cassandra 또는 기본적으로 Lift the Web Framework는 객체가 세션에 구체화되는 방법에 의존하지 않습니다. 또한, 세션 및 요청 사이클은 개방되어 트랜잭션 후크를 요청 / 응답 사이클에 삽입하는 것이 간단하다.
• Lift의 철학은 "서버 팀은 여러 언어가 아닌 하나의 언어를 알아야한다는 것"입니다. 이는 구성이 스칼라를 통해 수행됨을 의미합니다. 따라서 유연한 구성 옵션을 만들기 위해 Java 구문의 40 %를 XML 구문으로 구현할 필요가 없었습니다. 이는 컴파일러 구문과 구성 데이터 유형 검사를 통해 런타임시 이상한 XML 구문 분석이나 잘못된 데이터를 얻지 못하도록합니다. 즉, 사용중인 라이브러리를 기반으로 사용중인 주석의 세부 사항을 이해하는 IDE가 필요하지 않습니다.
• 그렇습니다. Lift의 문서는 장점이 아닙니다.

위에서 말한 것처럼 Lift의 디자인 철학에 대해 이야기하겠습니다.

I wrote Web Framework Manifesto before I started writing Lift. To a great degree, and to a greater degree than is true for any other web framework that I know of, Lift meets these goals.

Lift at its core seeks to abstract away the HTTP request/response cycle rather than placing object wrappers around the HTTP Request. At the practical level, this means that most any action that a user can take (submitting form elements, doing Ajax, etc.) is represented by a GUID in the browser and a function on the server. When the GUID is presented as part of the an HTTP request, the function is applied (called) with the supplied parameters. Because the GUIDs are hard to predict and session-specific, replay attacks and many parameter tampering attacks are far more difficult with Lift than most other web frameworks, including Spring. It also means that developers are more productive because they are focusing on user actions and the business logic associated with user actions rather than the plumbing of packing and unpacking an HTTP request. For example, code for accepting or rejecting a FourSquare friend request:

ajaxButton("Accept", () => {request.accept.save; 
                            SetHtml("acceptrejectspan", <span/>}) ++ 
ajaxButton("Reject", () => {request.reject.save; 
                            SetHtml("acceptrejectspan", <span/>})

It's that simple. Because the friendRequest is in the scope when the function is created, the function closes over the scope... there's no need to expose the primary key of the friend request or do anything else... just define the text of the button (it can be localized or it can be pulled from an XHTML template or it can be pulled from a localized template) and the function to execute when the button is pushed. Lift takes care of assigning the GUID, setting up the Ajax call (via jQuery or YUI, and yes, you can add your own favorite JavaScript library), doing automatic retries with back-offs, avoiding connection starvation by queuing Ajax requests, etc.

So, one big difference between Lift and Spring is that Lift's philosophy of GUID associated with function has the dual benefit of much better security and much better developer productivity. The GUID -> Function association has proven very durable... the same construct works for normal forms, ajax, comet, multi-page wizards, etc.

The next core piece of Lift is keeping the high level abstractions around for as long as possible. On the page generation side, that means building the page as XHTML elements and keeping the page as XHTML until just before streaming the response. The benefits are resistance to cross site scripting errors, the ability to move CSS tags to the head and scripts to the bottom of the page after the page has been composed, and the ability to rewrite the page based on the target browser. On the input side, URLs can be re-written to extract parameters (both query and path parameters) in a type-safe manner, high level, security checked data is available for processing very early in the request cycle. For example, here's how to define servicing of a REST request:

  serve {
    case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
    case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
  }

Using Scala's built-in pattern matching, we match an incoming request, extract the third part of the path and get the User that corresponds to that value, and even apply access control checks (does the current session or request have permissions to access the given User record). So, by the time the User instance hits the application logic, it's vetted.

With these two core pieces, Lift has a tremendous advantage in terms of security. To give you an idea of the magnitude of Lift's security that doesn't get in the way of features, Rasmus Lerdorg who did security for Yahoo! had this to say about FourSquare (one of the Lift poster-child sites):

Four stars to @foursquare - 1st site in a while I have taken a good look at that didn't have a single security issue (that I could find) -- http://twitter.com/rasmus/status/5929904263

At the time, FourSquare had one engineer working on the code (not that @harryh isn't a super-genius) and his main focus was re-writing the PHP version of FourSquare while coping with weekly traffic doubling.

The last part of Lift's security focus is SiteMap. It's a unified access control, site navigation, and menu system. The developer defines the access control rules for each page using Scala code (e.g. If(User.loggedIn _) or If(User.superUser _)) and those access control rules are applied before any page rendering starts. This is much like Spring Security, except that it's baked in from the beginning of the project and the access control rules are unified with the rest of the application so you don't have to have process for updating the security rules in XML when the URLs change or the methods that calculate the access control change.

To summarize so far, Lift's design philosophy gives you the benefits of baked in access control, resistance to the OWASP top 10 security vulnerabilities, much better Ajax support and much higher developer productivity than does Spring.

But Lift also gives you the best Comet support of any web framework around. That's why Novell chose Lift to power their Pulse product and here's what Novell has to say about Lift:

Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level features like the built-in Comet support allow you to focus on innovating instead of the plumbing. Building a rich, real-time web application like Novell Pulse requires a framework with the power of Lift under the covers.

So, Lift is not just another me-too MVC framework. It's a framework that's got some core design principles behind it that have matured very well. It's a framework that gives the dual advantages of security and developer productivity. Lift is a framework that's built in layers and gives the developer the right choices based on their needs... choices for view generation, choices for persistence, etc.

Scala and Lift give developers a much better experience than the melange of XML, annotations, and other idioms that make up Spring.

---

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.

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