23

最も一般的な MVC/MVVM クライアント側パターン ( Knockout.js、Angular.js、Ember.jsなど) を考えると、大きな疑問が 1 つあります。

また、両側のモデリングの冗長性を考慮して、MVC サーバー側パターンでこれらのクライアント側パターンを使用する利点と欠点は何ですか?

4

5 に答える 5

14

私はこの質問に答える方法に苦労しました...うまくいけば、たとえそれが回り道であっても、これが役立つことを願っています.

賛否両論のいくつかはすでに述べられていますが、最良の要約はこの回答にあると思います。

私にとって、クライアント側のロジックを使用する最大の利点は、豊富な UI の側面です。

しかし、あなたの質問の重要な部分は「モデルの冗長性」のようです(私はそれを重複したロジック、または少なくとも重複したロジックの可能性があると呼びます)。私の意見では、これは前のリンクの長所/短所とは関係なく存在する可能性がある問題です。

したがって、まず、クライアント側フレームワークを使用するかどうかの決定は、十分に文書化された長所と短所に基づいて行う必要があると思います。その決定が下されると、関連する問題を解決できます。

ある種のサーバー側フレームワーク/プラットフォームとクライアント側フレームワークを使用して、UI の対話性を少し提供していると仮定します。ここで、モデル ロジックを配置する場所 (クライアント、サーバー、またはその両方) に問題があります。

この問題を解決する 1 つの方法は、クライアントまたはサーバーのみでモデル ロジックを定義することです。その後、コードの重複はありませんが、高レベルの長所/短所のいくつかに影響します。

たとえば、モデル ロジックが 100% サーバー側である場合、UI のインタラクティブな部分の一部が失われます。または、サーバーとの間でモデルを常にスローしているため、いくつかの短所があります。

モデル ロジックが 100% クライアント側である場合、ビュー/モデルのサイズによっては、パフォーマンスの問題が発生する可能性があります。これが、Twitter がサーバー側の処理モデルに移行している理由の 1 つです。

次に、「両方」があります...クライアントとサーバーの両方にモデルロジックが存在します。ロジックが重複しない限り、これが最善の解決策だと思います。

たとえば、ショッピング カート ページでは、製品の価格とユーザーが編集可能な数量ボックスに基づいて注文のコストを再計算できます。このロジックはクライアントにのみ存在する必要があると思います。ロードされると変更されないその他のモデル プロパティは、サーバー上でホストされている可能性があります。

ここにはグレーな領域がたくさんあります... すべての卵を 1 つのバスケットに入れるのに苦労しています。たとえば、クライアント側のフレームワークを選択し、多くのクライアント側のロジックを作成すると、[仮説的に] パフォーマンスやブラウザーのサポートなどの問題が発生します。ここで、パフォーマンスのために 1 つか 2 つのページを微調整したい場合があります (Twitter のようにサーバー側に移動するなど)。しかし、コードをどのように構成するかを賢くすることは、その問題を軽減するのに役立つと思います。コードが保守可能でクリーンな場合、ロジックをクライアントからサーバーに移動することは難しくありません。

于 2012-08-08T19:31:16.117 に答える
5

利点は、サーバーが直接到達できないクライアントにクライアント側のパターンを適用できることです。リッチでインタラクティブなHTMLUIを構築している場合は、クライアント側のMVVMを使用してください。その場合でも、サーバー側のMVCは、適切なコンテンツをクライアントに配信するために関連している可能性があります。たとえば、ASP.NET WebAPIは、ASP.NETMVCフレームワークと同様のコントローラーアーキテクチャを持つHTTPAPIを作成するためのフレームワークです。このフレームワークで実装されたAPIは、クライアント側のコードによって呼び出され、サーバー側でMVC、クライアント側でMVVMになります。通常、MVCサーバー側とMVVMクライアント側を使用する場合、それぞれの責任は大きく異なるため、冗長性はありません。

于 2012-08-02T05:22:38.380 に答える
4

すでに実装されている MVC フレームワークに MVVM モデルを組み込むことも素晴らしいことです。最近、既に古い MVC フレームワーク (フレームワーク自体ではなく古いページ) に適合するように、いくつかの新しいプロジェクト ページにノックアウトを追加しました。

上記の回答が非常に高速な応答時間で優れたユーザーエクスペリエンスを提供すると述べているため、MVVMは素晴らしいと思います.バックラウンドで検証呼び出しを遅くすることなく非表示にすることができ、直感的です.

ただし、単体テストが非常に難しく、非常に大きな javascript ファイルを取得できるという問題があります。また、従来のシステムを IE6 で実行しているため、余分なコーディングを行う必要がありました。

ただし、MVVM と MVC を単独で使用する必要はありません。両方を使用します。しかし、3 レベルの検証があることには、いまだに悩まされています。

于 2012-08-08T09:56:51.660 に答える
2
  • 利点
    • これは揺るがすことができます。
  • 不利な点
    • あなたはそれをねじ込むことができます。

真剣に。フロントエンド ロジックの一部をブラウザーにトランスポートすることで、アプリケーション開発を後押しできます。なぜなら、より厳密なデータ処理をサーバー側でカプセル化しておく必要があるからです。

これは基本的にレイヤリングです。2 つのレイヤー、上のレイヤーは下のレイヤーと対話し、その逆も同様です。

[client] <--> [server]

通常、Json のような軽量のシリアル化形式で値オブジェクトを 2 つの間で交換します。

これは、サーバー側のドメイン オブジェクトがそれほど詳細ではない場合に、ユーザーが有用な構造に期待するものをかなりうまくマッピングできます。

ただし、ドメインオブジェクトをうまく作成できないと思うので、ある時点でサーバー側がjavascriptで書かれていない場合に真の力が発揮されます。その問題に遭遇した場合は、Scala (または同様の表現力のあるもの) を検討してください。

于 2012-08-10T11:58:17.400 に答える
2

この質問から 10 か月後、同じアプリケーション内で両方のパターンを使用しました。

唯一の問題は、モデルを 2 回マップする必要があることでした。

MVC (ASP.NET MVC 4 Web API)

最も重要なリソースはルートでした。

  • モデルは、データベースの相互作用に対して、およびコントローラーのアクションの引数として作成されました。
  • コントローラーは、API 要求を操作し、ビューをレンダリングするために作成されました。
  • ビューはサーバー側のモデルではなく、部分ビューとセクションのすべてのリソースでモデル化されました。

MVVM (ノックアウト.js)

  • モデルは、サーバー側モデルと同じプロパティで作成されました。
  • ビューはモデルのプロパティにバインドされ、ビューのサイズが大幅に縮小されました。
  • ビューモデルは、API メソッドから提供された値で作成されました。

全体として、MVC と MVVM の組み合わせは非常に便利でしたが、大きな専門知識と知識が必要でした。各アプリケーション層の責任について考える必要があるため、忍耐も必要です。

于 2013-06-25T16:27:40.077 に答える