0

ASP.NETMVC3を使用しています。

サーバー側でModel->ViewModelをマッピングするための少なくとも2つのアプローチに遭遇しました。

  • ViewModelクラスコンストラクター内
  • コントローラまたは指定されたマッパークラスの内部

ViewModelプロパティ宣言とそのマッピングが同じ場所にあり、保守と単体テストが簡単であるため、最初のアプローチが最も好きです。誰かがより多くの賛否両論、または他のより良い実践を指定できますか？

4

2 に答える 2

2

ViewModelsは、データベースから生成されたモデルクラスとは独立して存在できます。

ViewModelポピュレーションコードをコントローラー内に配置することはお勧めしません。これはコントローラーの責任ではないためです（また、メンテナンスの悪夢でもあります）。

私の意見では、ViewModelからDBModelへのマッピング（およびその逆）はViewModelの責任であるため、すべてのViewModelクラスは2つのメンバーを実装します。

public static TViewModel FromDBModel(TDBModel dbModel);

public void ToDBModel(TDBModel dbModel);

1つ目は、ビューを返すときにコントローラーが呼び出す静的メソッドです。staticメソッドは、ViewModelのインスタンスを作成し、それに応じてそのメンバーを設定します。

インスタンスのToDBModelメソッドには、構築されたDBModelインスタンスが渡されます（データの取得または更新時にリポジトリによって構築されるか、新しいデータの挿入時にコントローラーによって構築されます）。

HTH。

編集：多くの人がAutoMapper（リフレクションやその他のトリックを使用してDBModel <-> ViewModelマッピングプロセスを自動化する）などのライブラリを使用していることに注意してください。自動マッピングは開発者から制御を奪うため、私は自動マッピングのファンではありません。マッパーのしくみや、重要な操作をマッピングする方法を学ぶ必要があるときに、時間がかかるとは思いません。YMMV。

于 2012-07-17T00:02:24.360 に答える
0

私は、エンティティとビュー モデルを分離して、お互いを認識しないようにする傾向があります。これは、カプセル化を改善し、コントローラーとマッピング自体をテストする際の依存関係を最小限に抑えるためです。関心の分離を参照してください。

代わりに、(単純な場合) 自分でマッピングを実行するクラスを作成するか、AutoMapper を使用してコントローラー内からそのメソッドを使用します。数十または数百のデータベース エンティティとビューを持つ大規模なシステムの場合、私は AutoMapper に頼る傾向があります。マッピングを自分で記述するのは非常に面倒で、エラーが発生しやすくなります。自分で書くことの価値と、そのような実装がビジネスに与える価値とのバランスを取る必要があります。結局のところ、すべてのフレームワークについてすべてを知りたければ、それぞれ独自のバージョンの .NET フレームワークを作成することになります。:)

とはいえ、一部のシステム、特にビューの「フィールド」とデータベース エンティティの間で 1 対 1 のマッピングがあるシステム (典型的な CRUD) では、ビュー モデルを使用してもほとんどメリットがない場合があります。私は通常、それを見るとうんざりしますが、時間枠とシステムの複雑さを考えると、それは常にオプションです.

次に、ASP.NET MVC を使用して API を公開する場合があります。この場合、エンティティの「application/json」および「text/xml」表現は単なる「ビュー」です。ビュー モデルは、多くの場合、その外部プレゼンテーションから機密データや不要なデータをフィルター処理するために使用されます。この場合、同じエンティティに対して複数の表現 (およびそのバージョン) が存在する可能性があるため、マッピングはかなり複雑になります。ただし、これはOPの外にあるようです。

于 2012-07-17T01:17:26.920 に答える