9

私は現在、特にangularjsを使用したHTMLテンプレートへのクライアント側モデルのバインディングを検討しています。サーバーからクライアント側のビューモデルを取得するための最良の戦略は何か、たとえば、編集用のデータだけでなく、選択リストやドロップダウンリストなどのデータも含むビューモデル.

私が見ているように、いくつかのオプションがあります

  1. ビューモデルに必要なすべてのデータを含む、Web APIなどを使用してサーバーから1つのビューモデルを取得します
  2. クライアント側のビューモデルをサーバー側のhtml内のjavascriptにレンダリングします
  3. 複数の Web API 呼び出しを使用してビューモデルのデータを取得します。たとえば、編集するメイン データ用に 1 つと、追加データごとに 1 つ (選択リスト)。

オプション 1 の例はあまり見当たりませんでした。Web API は主に、Person や Order などの 1 つのタイプのオブジェクトの特定のデータを返す crud 操作に使用されているようです。

オプション 2 は、asp.net mvc を使用したサーバー側ビュー モデルのプラクティスに準拠していますが、この手法を angularjs と組み合わせて使用​​する例はあまり見たことがありません。

オプション 3 は、懸念事項の分離を考慮するときれいに見えますが、複数の小さな ajax リクエストがあるという欠点があります。

あなたの考えや経験を共有していただけますか？

4

2 に答える 2

2

個人的には、オプション #3 を使用します。アプリは、ドロップダウン リストの作成などの「エディターの準備」を要求し、編集するデータ (または、新しいオブジェクトを作成している場合は既定の初期値) をフェッチする要求を行います。これは、「モデル」データと「サポート」データを結び付けるオプション 1 よりも、問題をうまく分離できると思います。

しかし、あなたが指摘したように、これは余分な呼び出しを行います。呼び出しが非常に多い場合、ページの速度が著しく低下する可能性があります。(または複雑さを増します。多くの依存フィールドを持つ大きなフォームでは、順序付けが重要になる場合があります)。

私が通常行うことは、サーバーに「結合された」API (例: ) を提供させながら、/editor/prepare-all小さなピース (例: ) も提供させることです。エディターが読み込まれると、結合されたものを使用します。フィールド間に依存関係がある場合は、依存フィールドのデータのみを要求できます (例: )。これはサーバーの複雑さにほとんど影響を与えないと思います。/editor/prepare-dropdown-1/editor/prepare-dropdown-2/editor/prepare-dropdown-2?dropdown1-value=123

于 2013-04-22T07:21:27.223 に答える
1

私はセントに同意します。$resource と Web API を組み合わせることは、完璧な RAD の組み合わせになると思います。ただし、1 秒未満の応答時間を必要とする非常に複雑な画面にも取り組んできたので、開発の「列」全体を最適化することにしました。SQL Server をバックエンド データベースとして使用して開発したので、ストアド プロシージャから構造化された XML を返す XML のネイティブ サポート。.Net モデル (POCO) にシリアル化し、Json シリアライザーに渡してブラウザーに転送します。POCO に対して実行する追加のビジネス処理が必要になる場合がありますが、それでもかなり複雑なデータ構造を転送するための非常に単純なコード構造になります。通常、それも非常に高速です。

于 2013-04-22T10:35:52.027 に答える