私はこの質問が少しオープンであることを知っていますが、私はJava / Springの代替としてScala / Liftを検討しており、Scala / Liftがそれよりも優れている本当の利点は何だろうと思います。私の見解と経験から、Java AnnotationsとSpringは、アプリケーションに対して実行する必要があるコーディングの量を本当に最小限に抑えます。Scala / Liftはそれを改善しますか？
回答:
ScalaとJavaが同じくらい快適で、SpringまたはLiftに関係する場合を除いて、（大きな）言語の違いを無視してみましょう。
SpringとLiftは、成熟度と目標に関してほぼ正反対です。
文では、Springは重量級で、Liftは軽量です。十分な決意とリソースを使用すると、その頭の上にそれを回すことができますが、必要があるだろうたくさんの両方のを。
両方のフレームワークを使用した後に私の心に残った具体的な違いを次に示します。これは完全なリストではなく、どうしてもコンパイルすることはできません。私にとって最も興味深く思われたこと...
哲学を見る
Liftは、ビューの素材をスニペット/アクションメソッドに配置することを推奨しています。特にスニペットコードには、プログラムで生成されたフォーム要素（<div>s、<p>sなど）が散りばめられます。
特にScalaには言語レベルのXMLモードが組み込まれているため、これは強力で便利です。中括弧内の変数バインディングを含め、XMLをScalaメソッド内にインラインで書き込むことができます。これは、非常に単純なXMLサービスやサービスのモックアップに適している可能性があります。テンプレートや多くの付随する構成なしで、HTTP応答アクションのスイートを1つのすばらしい簡潔なファイルにまとめることができます。欠点は複雑さです。どこまで進んだかに応じて、ビューとロジックの間の懸念のあいまいな分離があるか、分離がないかのどちらかです。
対照的に、Spring for webappsを定期的に使用すると、ビューと他のすべてのものとが強力に分離されます。Springはいくつかのテンプレートエンジンをサポートしていると思いますが、私はJSPを真剣に使用しただけです。Liftにインスパイアされた「ファジーMVC」デザインをJSPで行うのは狂気でしょう。これは、単に読んで理解する時間が圧倒される可能性がある大規模なプロジェクトでは良いことです。
オブジェクトリレーショナルマッパーの選択
Liftの組み込みORMは「マッパー」です。「Record」と呼ばれる次の代替案がありますが、それでもプレアルファ版と見なされていると思います。LiftWeb Bookには、マッパーとJPAの両方の使用に関するセクションがあります。
LiftのCRUDify機能は、そのままの状態でMapperでのみ機能します（JPAでは機能しません）。
もちろん、Spring は標準的なデータベーステクノロジーや成熟したデータベーステクノロジーを幅広くサポートしています。そこには「サポート」という術語があります。Scalaから任意のJavaコードを呼び出すことができるため、理論的には、リフトで任意のJava ORMを使用できます。しかし、Liftが実際にサポートするのは、Mapperと（はるかに少ない範囲で）JPAだけです。また、Scalaでの重要なJavaコードの操作は、現在のところ、希望するほどシームレスではありません。Java ORMを使用すると、JavaとScalaの両方のコレクションをどこでも使用するか、すべてのコレクションをJavaコンポーネントの内外に変換することになるでしょう。
構成
Liftアプリは、アプリケーション全体の「Boot」クラスのメソッドを介してほぼ完全に設定されます。つまり、設定はScalaコードを介して行われます。これは、設定が簡単で、設定を行っている人がScalaを快適に編集できる場合に最適です。
Springは設定に関してかなり柔軟です。多くのconfオプションは、XML構成またはアノテーションのいずれかを介して駆動できます。
ドキュメンテーション
Liftのドキュメントは若いです。Springのドキュメントはかなり成熟しています。コンテストはありません。
Springのドキュメントはすでにうまく整理されており、見つけやすいので、Liftで見つけたドキュメントを確認します。Liftのドキュメントには、基本的に4つのソースがあります。LiftWebBook、API Docs、LiftWebのGoogleグループ、「はじめに」です。コード例の素敵なスイートもありますが、それ自体は「ドキュメント」とは呼びません。
APIドキュメントは不完全です。LiftWeb Bookは木の上で公開されていますが、オンラインでも無料で入手できます。確かに教訓的なスタイルは時々私を苛立たせましたが、それは本当に便利です。チュートリアルは少し長く、契約は短いです。Springには適切なマニュアルがありますが、Liftにはありません。
しかし、Liftには優れたサンプルセットがあります。Liftコードとサンプルコードを読み慣れている場合（そして、Scalaをすでに十分に理解している場合）、かなり短い時間で問題を解決できます。
どちらのフレームワークも魅力的です。どちらかを選択して上手に実行できる幅広いアプリがあります。
私はダン・ラロックの答えに強く同意しないと言わざるを得ません。
リフトはモノリシックではありません。個別の要素で構成されています。J / EE要素を無視せず、JNDI、JTA、JPAなどをサポートします。J/ EEのこれらの要素の使用を強制されないという事実は、Liftのモジュール設計の強力な兆候です。
以上を踏まえて、Liftの設計哲学について少しお話ししましょう。
私が書いたWebフレームワーク宣言を私はリフトを書き始めた前に。かなりの程度まで、そして私が知っている他のどのWebフレームワークについてもそうであるよりも、Liftはこれらの目標を満たしています。
Liftのコアは、HTTPリクエストの周囲にオブジェクトラッパーを配置するのではなく、HTTPリクエスト/レスポンスサイクルを抽象化することを目的としています。実際のレベルでは、これは、ユーザーが実行できるほとんどすべてのアクション（フォーム要素の送信、Ajaxの実行など）が、ブラウザーのGUIDとサーバーの関数によって表されることを意味します。GUIDがHTTPリクエストの一部として提示されると、指定されたパラメーターを使用して関数が適用（呼び出）されます。GUIDは予測が難しく、セッション固有であるため、Springを含む他のほとんどのWebフレームワークよりも、リフトを使用したリプレイ攻撃や多くのパラメーター改ざん攻撃ははるかに困難です。また、開発者は、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の大きな違いの1つは、Liftの機能に関連付けられたGUIDの哲学には、セキュリティの向上と開発者の生産性の向上という二重の利点があることです。GUID->関数の関連付けは非常に耐久性があることが証明されています...同じ構造が通常のフォーム、ajax、彗星、マルチページウィザードなどでも機能します。
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の組み込みパターンマッチングを使用して、着信要求を照合し、パスの3番目の部分を抽出して、その値に対応するユーザーを取得し、さらにアクセス制御チェックを適用します（現在のセッションまたは要求には、特定のユーザーレコード）。したがって、Userインスタンスがアプリケーションロジックに到達するまでに、吟味されます。
これら2つの中核部分を備えたLiftは、セキュリティの点で非常に優れています。機能の邪魔にならないLiftのセキュリティの大きさを理解するために、Yahoo！のセキュリティを担当したRasmus Lerdorg氏。FourSquare（Liftのポスター-子サイトの1つ）についてこう言っています：
@foursquareへの4つ星-しばらくして最初のサイトをよく見ましたが、セキュリティ上の問題は1つもありませんでした（見つけることができました）-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の設計哲学は、アクセス制御の強化、OWASPのトップ10のセキュリティ脆弱性への耐性、Springよりはるかに優れたAjaxサポートおよびはるかに高い開発者の生産性の利点を提供します。
しかし、Liftはまた、周りのWebフレームワークの中で最高のCometサポートを提供します。それが、NovellがPulse製品を強化するためにLiftを選択した理由であり、NovellはLiftについて次のように述べています。
リフトは、開発者が全体像に集中できるようにする一種のWebフレームワークです。強力で表現力豊かなタイピングと、ビルトインのCometサポートなどのより高度な機能により、配管の代わりに革新に集中できます。Novell PulseのようなリッチでリアルタイムのWebアプリケーションを構築するには、Liftの機能を備えたフレームワークが必要です。
したがって、Liftは単なる別のMVCフレームワークではありません。それは、非常によく成熟した、その背後にあるいくつかのコアデザイン原則を備えたフレームワークです。これは、セキュリティと開発者の生産性という二重の利点をもたらすフレームワークです。Liftはレイヤーに組み込まれたフレームワークであり、開発者がニーズに基づいて適切な選択を行えるようにします...ビュー生成の選択、永続化の選択など。
ScalaとLiftは、Springを構成するXML、注釈、その他のイディオムのメランジよりもはるかに優れたエクスペリエンスを開発者に提供します。
Spring MVCの大ファンではなく、最近のWebプロジェクトでLiftを使用することを強く検討しました。私は最新バージョンを使用していませんが、Spring MVCの以前のバージョンでは、Webアプリケーションを実行するために多くのフープを飛ばしてしまいました。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)したがって、言語の選択は重要です。フレームワークもそうです。ここには何を選ぶべきかをアドバイスする賢い人がたくさんいますが、最終的には、あなたの想像力を最もよく翻訳する言語/フレームワークがあなたの選択でなければなりません。したがって、両方でプロトタイプを作成して、選択を行います。
私については、ScalaとLiftをゆっくりと学習し、愛しています。