2

シングル ページ アプリケーションのクライアント側で、knockout.js と MVVM パターンを使用する予定です。したがって、Models、ViewModels はクライアント側で定義されます。サーバー側でどのように構造化する必要があるかについて混乱しています。

  1. さて、コントローラーはドメインモデル自体を返すだけでしょうか? ドメイン モデルから ViewModel へのすべてのマッピングは、クライアント側でのみ行われますか?

  2. 私のソリューションでは、Domain モデルと ViewModel の間に大きなギャップがあります。したがって、上記のアプローチでは、大量のデータが不必要にクライアント側に返されます。やり過ぎのように思えますが、ViewModel と InputViewModel の定義 (前者はレンダリングされたデータを表し、後者はコントローラー アクションに戻されるデータを表します) をサーバー側で繰り返し、ドメイン モデルをマップするためのマッピング レイヤー (オートマッパーに基づく) を使用することも考えています。サーバー側のViewModelに。これは理にかなっていますか？または、より良いアプローチがありますか？

4

3 に答える 3

2

ビュー モデルに実際に必要なデータを特定し、そのデータを含むサーバー側のビュー モデルをコントローラーで構築して、JSON 形式でクライアントに送信することをお勧めします。

このようにして、不要なデータをクライアントに送信する (または返す) ことはなく、サーバー上で多くの面倒な作業を行うことができ、ノックアウト ビュー モデルは本来の目的を果たすことができます。つまり、使用するデータを提示することです。ビューによって。

于 2012-05-03T15:56:15.370 に答える
1

ポイント2で説明したのは、実際に私が最もよく使用するソリューションであり、私には理にかなっています。サーバー側でAutomapperを使用して、ビュー固有でデータのみを含むドメインモデルとViewModel（.Netオブジェクト）の間でマッピングします。ニーズを表示します。ビューの最初のロードを担当するコントローラーアクションは、ビューをViewModelにデータバインドするため、Ajax呼び出しを行うことなくページがすばやく初期化されます。ビュー自体で、ノックアウトビューモデルを作成し、境界のあるViewModelをエンコードするJsonによって（必要に応じて）初期値を割り当てます（たとえば、Asp.Net MVCを使用して次のようにします）

var boundedViewModel = @Html.Raw(Json.Encode(Model));
于 2012-05-04T08:23:08.647 に答える
0

それがまさに私がこの問題に取り組む方法です。これが単純な MVC アプリである場合は、引き続きビューモデルを作成します。

複雑なデータ セットの場合、backbone.js の豊富なデータ モデルを取得し、knockout.js と組み合わせた Knockback のようなものを使用するユース ケースを見ることができます http://kmalakoff.github.com/knockback/

于 2012-05-03T15:51:20.410 に答える