3

mvc3アプリのデザインの問題に直面しています。カテゴリのリストを持つビューモデルProductCreateModelがあります。

現在、コントローラーでカテゴリリストを設定していますが、ProductCreateModelコンストラクターでデータソースを検出することをお勧めします。

ビューモデルは、データソースから依存データを読み取ることも知っているファットモデルである必要があると思いますか？...またはこれはコントローラーのものですか？

4

4 に答える 4

6

ビュー モデルはライト モデルであるべきだと思います。ビュー モデルが関連データを読み取る唯一の方法は、実際にラップするモデルである「親」オブジェクトのプロパティであるべきだと思います。

ほとんどの場合、ビュー モデルはプロパティを持つ単なるクラスであり、すべてのロジックはコントローラーまたはサービス クラスにあります (そうでなければコントローラーに配置される多くのロジックについて話している場合)。これはすべて、テストを容易にするためです。

于 2012-07-31T12:54:01.217 に答える
6

私は、データ層について何も知らないスリムなビューモデルを好みます。それらは管理が簡単です（私の経験では）。

于 2012-07-31T12:52:24.587 に答える
3

MVC を学んだとき、「経験則」はスキニー コントローラー、ファット モデル、ダム ビューであると教えられました。多くの MVC 開発者が犯す間違いは、Fat Controllers (ロジックが多すぎる)、Skinny Models (基本的にデータを保持するための POCO クラス)、および Smart Views (If this、Else that などを使用した一連の Razor 構文) です。

何年にもわたって、私は Skinny Controllers、Fat Models、Dumb views のアプローチに固執してきましたが、それは私にとってはうまくいきました。ここで、これは ViewModel ではなくモデルに関連していることを考慮してください。通常、モデルはまったく別のレイヤー (つまり、proj またはフォルダー) にある必要があります。一方、ViewModel はかなり単純なはずです。これにより、テストが容易になり、再利用しやすくなります。ViewModel を構築するために何らかのサービス、レポ、またはその他の依存関係が必要であることがわかっている場合は、おそらくそのロジックをある種の Composer クラスに抽象化する必要があります。過去に、IViewModelManager を実装する ViewModelManager を使用して、必要に応じて ViewModel を作成しました。このようにして、IViewModelManager をコントローラーに挿入し、それを使用して ViewModel を構築できます。次に、ViewModelManager の実装で、

このアプローチには、間違いなくより多くのコードとより多くのクラスが必要ですが、適切なレベルの粒度と分離が得られ、DRY 原則と単一責任がサポートされます。

ハッピーコーディング！

于 2015-01-06T18:18:07.500 に答える
0

原則として、そうしたくないと思います。

そのルールの例外として、ドロップダウンを作成するときにエディター テンプレートで Service Locator を少し使い始めました。ドロップダウンを設定する複数の方法を経験しました (一般に、コレクションをビュー モデルまたはビュー データに追加する何らかの形式)。エディター テンプレートで SL を使用してデータを取得し、選択リストに変換するビデオを見ました。私の最初の反応は「うーん、そうですか」でしたが、考えれば考えるほど、それは理にかなっています.

于 2015-01-06T18:32:01.673 に答える