151

私はこの質問が少しオープンであることを知っていますが、私はJava/Springの代わりとしてScala/Liftを検討してきました。そして、Scala/Liftがそれに対して持つ本当の利点は何でしょうか。私の観点と経験から、Java AnnotationsとSpringは、アプリケーションに対して実行する必要のあるコーディングの量を実際に最小限に抑えます。Scala / Liftはそれを改善しますか？

4

10 に答える 10

229

私はダン・ラロックの答えに強く反対していると言わざるを得ません。

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

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

以上を踏まえて、Liftのデザイン哲学についてお話させていただきます。

私はLiftを書き始める前に、WebFrameworkManifestoを書きました。かなりの程度、そして私が知っている他のWebフレームワークに当てはまるよりもはるかに、Liftはこれらの目標を満たしています。

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

リフトの次のコア部分は、高レベルの抽象化を可能な限り長く維持することです。ページ生成側では、これは、ページを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！のセキュリティを担当したRasmusLerdorg氏。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 _)）を使用して各ページのアクセス制御ルールを定義し、それらのアクセス制御ルールは、ページのレンダリングが開始される前に適用されます。これはSpringSecurityによく似ていますが、プロジェクトの最初から組み込まれており、アクセス制御ルールがアプリケーションの他の部分と統合されているため、URLのときにXMLでセキュリティルールを更新するプロセスが必要ありません。変更またはアクセス制御の変更を計算するメソッド。

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

しかし、Liftは、あらゆるWebフレームワークの中で最高のCometサポートも提供します。そのため、NovellはPulse製品に電力を供給するためにLiftを選択しました。また、NovellがLiftについて述べていることは次のとおりです。

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

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

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

于 2010-06-18T05:07:41.037 に答える
113

私たちがScalaとJavaで同じように快適であると仮定し、SpringまたはLiftに関係する場合を除いて、（巨大な）言語の違いを無視しましょう。

春とリフトは、成熟度と目標の点でほぼ正反対です。

  • 春はリフトより約5年古い
  • リフトはモノリシックで、ウェブのみを対象としています。Springはモジュール式であり、Webアプリと「通常の」アプリの両方を対象としています
  • Springは多数のJavaEE機能をサポートしています。リフトはそのようなものを無視します

一言で言えば、Springはヘビー級で、Liftは軽量です。十分な決意とリソースがあれば、それを真っ向から変えることができますが、両方がたくさん必要になります。

両方のフレームワークを使用した後に頭に浮かんだ具体的な違いは次のとおりです。これは完全なリストではなく、とにかくコンパイルすることはできません。私にとって最も興味深いと思われたもの...

  1. 哲学を見る

    Liftは、ビューマテリアルをスニペット/アクションメソッドに配置することを推奨しています。特にスニペットコードには、プログラムで生成されたフォーム要素、<div>s、<p>sなどが散りばめられます。

    これは、特にScalaに言語レベルのXMLモードが組み込まれているため、強力で便利です。中かっこでの変数バインディングを含め、Scalaメソッド内でXMLをインラインで記述できます。これは、非常に単純なXMLサービスやサービスのモックアップに適しています。テンプレートや多くの付随する構成なしで、一連のHTTP応答アクションをすべて1つの見事に簡潔なファイルにまとめることができます。欠点は複雑さです。どこまで進んでいるかに応じて、ビューとロジックの間に関心の分離があいまいになるか、分離されないかのどちらかです。

    対照的に、WebアプリケーションにSpringを定期的に使用すると、ビューと他のすべてのものが強力に分離されます。Springはいくつかのテンプレートエンジンをサポートしていると思いますが、私はJSPを使用したのは深刻なものだけです。リフトに着想を得た「ファジーMVC」デザインをJSPで実行すると、狂気になります。これは、読んで理解するだけの時間が圧倒される可能性がある大規模なプロジェクトでは良いことです。

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

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

    LiftのCRUDify機能は、そのままでもかっこいいですが、Mapperでのみ機能します（JPAでは機能しません）。

    もちろん、Springは標準および/または成熟したデータベーステクノロジーの全貌をサポートしています。そこにある有効な言葉は「サポート」です。理論的には、Scalaから任意のJavaコードを呼び出すことができるため、Liftで任意のJavaORMを使用できます。しかし、Liftは実際にはMapperと（はるかに少ない程度で）JPAのみをサポートします。また、Scalaでの重要なJavaコードの操作は、現在、思ったほどシームレスではありません。Java ORMを使用すると、JavaコレクションとScalaコレクションの両方をどこでも使用するか、すべてのコレクションをJavaコンポーネントに変換したりJavaコンポーネントから変換したりすることに気付くでしょう。

  3. 構成

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

    Springは構成に関してかなり柔軟性があります。多くのconfオプションは、XML構成または注釈のいずれかを介して駆動できます。

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

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

    Springのドキュメントはすでにうまく整理されていて見つけやすいので、Liftで見つけたドキュメントを確認します。Liftのドキュメントには、基本的に4つのソースがあります。LiftWebBook、API Docs、LiftWebのGoogleグループ、および「 GettingStarted 」です。コード例の素晴らしいスイートもありますが、それ自体は「ドキュメント」とは呼びません。

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

    しかし、Liftには素晴らしい例があります。リフトコードとサンプルコードを読むことに慣れている場合（そしてScalaをすでによく知っている場合）、かなり短い順序で問題を解決できます。

どちらのフレームワークも魅力的です。どちらかを選択してうまくいくアプリはたくさんあります。

于 2010-04-22T01:06:48.140 に答える
11

Play Frameworkを確認することをお勧めします。これには非常に興味深いアイデアがいくつかあり、JavaとScalaでの開発をサポートしています。

于 2010-04-24T01:24:49.473 に答える
10

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

于 2010-04-21T14:42:36.177 に答える
10

私は、Spring MVCの大ファンではなく、最近のWebプロジェクトにLiftを使用することを強く検討しました。私は最新バージョンを使用していませんが、Spring MVCの以前のバージョンでは、Webアプリケーションを実行するために多くのフープを飛び越えていました。リフトはセッションに非常に依存する可能性があり、正しく機能するには「スティッキーセッション」が必要になることがわかるまで、私はほとんどリフトで売られていました。http://exploring.liftweb.net/master/index-9.html#sec:Session-Managementからの抜粋

標準のセッションレプリケーションテクノロジーが登場するまでは、「スティッキーセッション」を使用してアプリケーションをクラスター化できます。これは、HTTPセッションに関連するすべてのリクエストを同じクラスターノードで処理する必要があることを意味します

したがって、セッションが必要になると、ユーザーはそのノードにピン留めする必要があります。これにより、インテリジェントな負荷分散が必要になり、スケーリングに影響を与えるため、私の場合、Liftがソリューションになるのを妨げていました。最終的にhttp://www.playframework.org/を選択し、非常に満足しています。Playはこれまでのところ安定していて信頼性が高く、操作が非常に簡単です。

于 2012-03-15T19:37:12.867 に答える
7

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

于 2010-04-21T19:27:58.527 に答える
3

あなたの知識を広げることは常に価値のある努力です:)私はScalaを学び始めたばかりです、それは私が通常のJavaを書く方法に影響を与えており、これまでのところ非常に有益であると言えます。

于 2010-04-21T15:37:08.533 に答える
3

私はあなたの世界を完全にループに投げ込むのは嫌いです。しかし、1つのアプリケーションでScala、Java、Lift、Springを使用でき、問題はありません。

于 2010-04-23T21:33:43.793 に答える
0

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

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

Real app = programming language (imagined app)

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

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

于 2012-03-25T11:27:57.720 に答える
0

しかし、主な問題は、スプリングとリフトを比較できないことです。Liftは基本的にUIフレームワークとして使用され、SpringはDIフレームワークとして使用されます。
バックエンドの多くを備えたWebアプリを開発している場合は、リフトを使用できることを確認してください。
ただし、いくつかのシリーズバックエンドを備えた開発中のWebアプリで、明確に春に行く必要がある場合。

于 2012-11-06T14:51:57.167 に答える