web-dev-qa-db-ja.com

Java / SpringではなくScala / Liftを使用するのはなぜですか？

私はこの質問が少し開かれていることを知っていますが、私はScala/LiftをJava/Springに代わるものとして探していました。私の観点と経験から、Java Annotations and Springは、アプリケーションに対して行う必要のあるコーディングの量を本当に最小限に抑えます。Scala/ Liftはそれを改善しますか？

javaspringscalalift
151
Chris J

ScalaとJavaでも同様に快適であると仮定し、SpringまたはLiftに関連する場合を除き、（巨大な）言語の違いを無視します。

SpringとLiftは、成熟度と目標に関してほぼ正反対です。

  • 春はLiftより5年ほど古い
  • Liftはモノリシックであり、ウェブのみを対象としています。 Springはモジュール式であり、ウェブアプリと「通常の」アプリの両方を対象としています
  • Springは、Java EE機能。Liftはそのようなものを無視します。

文では、Springは重量級で、Liftは軽量です。十分な判断力とリソースがあれば、それを頭に置くことができますが、両方のlotが必要です。

両方のフレームワークを使用した後、私の心に残った具体的な違いを以下に示します。これはすべてを網羅したリストではありません。コンパイルすることはできません。一番面白そうだったのは...

  1. 哲学を見る

    Liftでは、スニペット/アクションメソッドにビュー資料を配置することをお勧めします。特にスニペットコードには、プログラムで生成されたフォーム要素<div>s、<p>sなど.

    これは強力で便利です。特にScalaには言語レベルのXMLモードが組み込まれています。中括弧内の変数バインディングを含む、Scalaメソッド内でXMLをインラインで記述できます。これは、非常に単純なXMLサービスまたはサービスのモックアップにとっては喜ばしいことです-テンプレートや多くの付随する構成なしに、HTTP応答アクションのスイートをすべて1つの見事な簡潔なファイルにバングアウトできます。行く、ビューとロジックの間の懸念のあいまいな分離があるか、分離がない。

    対照的に、webappsにSpringを定期的に使用すると、ビューと他のすべてのものとの間に強い分離が強制されます。 Springはいくつかのテンプレートエンジンをサポートしていると思いますが、私はJSPを深刻なものでしか使用していません。 Liftにインスパイアされた「ファジーMVC」デザインをJSPで実行するのは気の狂ったことでしょう。これは、大規模なプロジェクトでは良いことです。ただ読むだけで理解するのに時間がかかる場合があります。

  2. オブジェクトリレーショナルマッパーの選択

    Liftの組み込みORMは「マッパー」です。 「レコード」と呼ばれる今後の選択肢がありますが、まだプレアルファと見なされていると思います。 LiftWeb Bookには、MapperとJPAの両方の使用に関するセクションがあります。

    Liftの CRUDify 機能はそのままで、マッパーでのみ機能します（JPAでは機能しません）。

    もちろん、Springは 標準および/または成熟したデータベーステクノロジーのパノラマ をサポートしています。そこに有効な言葉は「サポート」です。理論的には、任意のJava ORMとLiftを使用できます。Scalaから任意のJavaコードを呼び出すことができます。しかし、Liftは実際にMapperと（また、重要ではないJavaのコードScalaは、現在のようにシームレスではありません; Java ORM、おそらく、JavaとScalaコレクションをどこでも使用するか、Javaコンポーネント。

  3. 設定

    Liftアプリは、アプリケーション全体の「ブート」クラスというメソッドを介してほぼ完全に構成されます。言い換えれば、設定はScalaコードを介して行われます。これは短い設定のプロジェクトに最適であり、設定を行う人がScalaを快適に編集できる場合に最適です。

    Springは設定の点で非常に柔軟です。多数のconfオプションは、XML構成または注釈を通じて駆動できます。

  4. ドキュメンテーション

    Liftのドキュメントは新しいものです。 Springのドキュメントはかなり成熟しています。コンテストはありません。

    Springのドキュメントは既に整理されていて見つけやすいので、Liftで見つけたドキュメントを確認します。 Liftドキュメントには、基本的に4つのソースがあります： LiftWeb Book 、 API Docs 、LiftWebの Googleグループ 、および " Getting Started "。ニースのコード例もありますが、それを「ドキュメント」とは呼びません。

    APIドキュメントは不完全です。 LiftWeb Bookは木で公開されていますが、オンラインでも無料で入手できます。確かに教訓的なスタイルは時々私をいらいらさせますが、それは本当に便利です。チュートリアルは少し長く、契約は短いです。 Springには適切なマニュアルがありますが、Liftにはありません。

    ただし、Liftにはニースのサンプルセットがあります。 Liftのコードとサンプルコードを読みやすい場合（そしてScala既に知っている場合）、かなり短い順序で問題を解決できます。

両方のフレームワークは魅力的です。幅広いアプリがあり、どちらかを選択してうまくいくことができます。

113
Dan LaRocque

Dan LaRocqueの答えには強く反対すると言わざるを得ません。

リフトはモノリシックではありません。個別の要素で構成されます。 J/EE要素を無視せず、JNDI、JTA、JPAなどをサポートします。J/ EEのこれらの要素を使用することを強制されていないという事実は、Liftのモジュール設計の強力な指標です。

  • Liftの考え方は、「開発者に決めてもらう」ことです。 Liftは、ビュー内のロジックコードを許可しないテンプレートメカニズム、ScalaコードとScalaのXMLリテラルの実行に基づくビューメカニズム、および Scalate に基づくビューメカニズムを提供します。 XMLテンプレートメカニズムを選択する場合、マークアップがビジネスロジックに属する場合、そのマークアップを選択します。 Liftのビューの分離は、LiftのXMLテンプレートでビジネスロジックを表現できないため、Springが提供するものよりも強力です。
  • Liftのオブジェクト↔永続性の哲学は、「開発者に決定させる」ことです。 Liftには、ActiveRecordスタイルのオブジェクトリレーショナルマッパーであるマッパーがあります。小規模なプロジェクトの仕事を完了します。サポートJPAを持ち上げます。 Liftには、リレーショナルデータベースへの出入り、NoSQLストアへの出入りをサポートするRecord抽象化があります（LiftにはCouchDBおよびMongoDBのネイティブサポートが含まれていますが、アダプターレイヤーは数百行のコードなので、Cassandraまたは他の何か、それを取得するのはそれほど手間がかかりません。）基本的に、Lift the Web Frameworkはオブジェクトがセッションに具体化される方法に依存しません。さらに、セッションとリクエストのサイクルが開いているため、リクエスト/レスポンスサイクルにトランザクションフックを簡単に挿入できます。
  • Liftの哲学は、「サーバーチームは複数の言語ではなく1つの言語を知る必要がある」というものです。つまり、構成はScalaを介して行われます。これは、柔軟な構成オプションを作成するために、XML構文でJavaの言語構成の40％を実装する必要がなかったことを意味します。これは、コンパイラー構文と構成データが構成データをチェックするため、実行時に奇妙なXML解析や誤ったデータが取得されないことを意味します。つまり、使用しているライブラリに基づいて、使用しているアノテーションの詳細を理解するIDEが必要ないということです。
  • はい、Liftのドキュメントはその長所ではありません。

上記のことを述べながら、Liftの設計哲学についてお話しましょう。

Liftを書き始める前に Web Framework Manifesto と書きました。 Liftは、私が知っている他のすべてのWebフレームワークに当てはまることよりもはるかに多く、これらの目標を達成しています。

Liftのコアは、HTTPリクエストの周りにオブジェクトラッパーを配置するのではなく、HTTPリクエスト/レスポンスサイクルを抽象化することを目指しています。実用レベルでは、これは、ユーザーが実行できるほとんどのアクション（フォーム要素の送信、Ajaxの実行など）が、ブラウザーのGUIDとサーバー上の機能によって表されることを意味します。 GUIDがHTTP要求の一部として提示されると、提供されたパラメーターを使用して関数が適用（呼び出し）されます。 GUIDは予測が難しく、セッション固有であるため、リプレイ攻撃と多くのパラメーター改ざん攻撃は、LiftではSpringを含む他のほとんどのWebフレームワークよりもはるかに困難です。また、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の大きな違いの1つは、機能に関連するLiftのGUIDの哲学には、セキュリティと開発者の生産性が大幅に向上するという2つの利点があることです。 GUID->関数の関連付けは非常に永続的であることが証明されています...通常のフォーム、ajax、comet、複数ページのウィザードなどで同じ構成が機能します。

Liftの次のコア部分は、高レベルの抽象化を可能な限り長く維持することです。ページ生成側では、それはページをXHTML要素として構築し、応答をストリーミングする直前までページをXHTMLとして保持することを意味します。利点は、クロスサイトスクリプティングエラーに対する耐性、CSSタグをページに構成した後に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のセキュリティが機能の邪魔にならないことの大きさを知るために、 Rasmus Lerdorg Yahoo!のセキュリティを担当したのは誰ですか？ FourSquare（Liftのポスター子サイトの1つ）について次のように言いました：

@foursquareの星4つ-しばらくして最初のサイトをよく見てきましたが、セキュリティの問題は1つも見つかりませんでした（見つけることができました）- http://Twitter.com/rasmus/status/592990426

当時、FourSquareにはコードに取り組んでいたエンジニアが1人いて（@harryhが超天才ではない）、彼の主な焦点は、毎週のトラフィックの倍増に対処しながら、FourSquareのPHPバージョンを書き直すことでした。

Liftのセキュリティフォーカスの最後の部分はSiteMapです。統合されたアクセス制御、サイトナビゲーション、およびメニューシステムです。開発者は、Scalaコード（例：If(User.loggedIn _)またはIf(User.superUser _)）を使用して各ページのアクセス制御ルールを定義し、それらのアクセス制御ルールはページのレンダリングが開始される前に適用されます。これはSpring Securityによく似ていますが、プロジェクトの最初から組み込まれ、アクセス制御ルールがアプリケーションの他の部分と統合されているため、URLが更新されたときにXMLのセキュリティルールを更新するプロセスが不要です。変更またはアクセス制御の変更を計算するメソッド。

これまでのことをまとめると、Liftの設計哲学は、アクセス制御の強化、OWASPのセキュリティ脆弱性トップ10への耐性、Ajaxサポートの改善、およびSpringよりもはるかに高い開発者生産性の利点を提供します。

ただし、Liftは、あらゆるWebフレームワークのCometサポートを提供します。そのため、NovellがLiftを使用して パルス製品 を駆動し、NovellがLiftについて次のように述べています。

Liftは、開発者が全体像に集中できるようにするWebフレームワークの一種です。強力で表現力豊かなタイピングと組み込みのCometサポートなどの高レベルの機能により、配管ではなく革新に集中できます。 Novell PulseのようなリッチでリアルタイムのWebアプリケーションを構築するには、Liftの力を秘めたフレームワークが必要です。

したがって、Liftは単なるMVCフレームワークではありません。それは非常に成熟したいくつかのコア設計原則の背後にあるフレームワークです。これは、セキュリティと開発者の生産性という2つの利点を提供するフレームワークです。 Liftは、レイヤーに組み込まれたフレームワークであり、開発者にニーズに基づいた正しい選択を提供します。ビュー生成の選択、永続性の選択などです。

ScalaとLiftは、開発者に、Springを構成するXML、アノテーション、その他のイディオムのメランジよりもはるかに優れたエクスペリエンスを提供します。

229
David Pollak

Playフレームワークを確認することをお勧めします。非常に興味深いアイデアがあり、JavaとScalaでの開発をサポートしています

11
IPC

ただ楽しみのために。そして、新しいプログラミングアプローチを学ぶために。

10
Roman

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/ を選択し、非常に満足しています。プレイはこれまで安定しており、信頼性が高く、操作が非常に簡単です。

10
mguymon

I なかった Liftに来て、ScalaからJavaバックグラウンドであるため、これは個人的な経験からではありませんが、多くのLift開発者がScala=はJavaよりもはるかに簡潔で効率的な言語であると感じていることを知っています。

7
pr1001

ループのためにあなたの世界を完全に投げることは嫌いです。しかし、1つのアプリケーションでScala、Java、Lift、Springを使用して、問題にならないようにすることができます。

3
Berlin Brown

あなたの知識を広げることは常に価値のある努力です:)私はScalaを学び始めたばかりで、普通のJavaの書き方に影響を与えています。

3
gpampara

しかし、主な問題は、スプリングとリフトを比較できないことです。 Liftは基本的にUIフレームワークとして使用され、SpringはDIフレームワークとして使用されます。
バックエンドの量が多いWebアプリを開発している場合は、liftを使用できます。
[。

0
Rajith Delantha

私の謙虚な意見では、想像力が重要です。

アプリを書きたいと考えてみましょう。あなたがまともな開発者であれば、アプリはすでに頭の中で構築されているはずです。次のステップは、コードを通じてどのように機能するかを発見することです。そのためには、想像したアプリを、実世界のアプリに変換する関数に渡す必要があります。その関数はプログラミング言語です。そう

Real app = programming language (imagined app)

そのため、言語の選択が重要です。フレームワークも同様です。ここにはたくさんの賢い人がいて、何を選ぶべきかアドバイスしてくれますが、最終的には、あなたの想像力を最もよく翻訳する言語/フレームワークがあなたの選択であるはずです。両方でプロトタイプを作成し、選択してください。

私に関しては、ゆっくりとScalaとLiftとそれを愛しています。

0
Matei Alexandru Bogdan