0

私のアプリケーションは現在、モデルがシンで mvc ブラインドであるサービス パターンに従っており、コントローラーはモデルからデータを取得するサービスを呼び出します。

現在、コントローラーは、サービスまたはクライアントから取得したデータに基づいて ViewModel を構築および使用しています。

私が疑問に思っているのは、ViewModel クラスをサービス層に再配置するのが賢明でしょうか?

前:

  1. コントローラーがサービスにデータを要求する
  2. コントローラーはデータを受け取り、viewModel を構築します
  3. コントローラーがビューモデルをクライアントに送信する
  4. クライアントがデータをコントローラーに送り返す
  5. コントローラーはviewModelからデータを取得し、サービスに送り返してdbを更新します

  1. コントローラーがサービスにデータを要求する
  2. Service は viewModel を構築し、それにデータを入力します
  3. コントローラーはviewModelを受け入れます
  4. コントローラーがビューモデルをクライアントに送信する
  5. クライアントがデータをコントローラーに送り返す
  6. コントローラーはviewModelをサービスに転送します
  7. サービスはデータを分離し、必要に応じて更新/クエリを実行します

一方が他方より優れているか?なんで?

4

1 に答える 1

3

前がより良いアプローチです。名前が示すように、ビューモデルはビューのモデルである必要があります。

サービスによって取得されたデータが含まれている場合がありますが、その特定のビューに必要な追加データで拡張される可能性もあります。

また、ビューモデルはUIテクノロジー固有である可能性が高いのに対し、サービスは完全にUIに依存しない必要があります。サービスコードはUIテクノロジ間で再利用できる可能性がありますが、ビューモデルコードは再利用できない可能性があります。

実際、ファットクライアントアプリケーションでは、ビューモデルは単なるデータ転送オブジェクトではなく、プレゼンテーションロジックを含み、ユーザー状態などを管理する可能性があります。サービスコードは、特定のクライアント実装に関連付けられていない可能性があります。 。

于 2013-02-17T21:15:06.977 に答える