0

新しいユーザーを作成するコントローラー アクションを作成していました。現在、コントローラー アクションはユーザー エンティティ モデルをパラメーターとして受け取ります。

独自のビューモデルでフロントエンドから値を渡し、値を抽出してバックエンドでエンティティを作成する必要があるかどうか疑問に思っていましたか?

public ActionResult AddUser(User user)
{
  context.Users.Add(user);
  context.SaveChanges();
}

対

public ActionResult AddUser(UserViewModel userViewModel)
{
  var user = new User(userViewModel.Name);
  context.User.Add(user);
  context.SaveChanges();
}

ありがとう！

4

2 に答える 2

1

アカデミックな方法は、2番目の例のように、表示する必要のあるデータまたはユーザーが情報を入力してドメインモデルにマップするために必要なフィールドだけを公開する追加のviewmodelクラスを作成することです。

ただし、小さなアプリの場合、またはモデル内のすべてのフィールドが必要な場合は、ドメインモデルオブジェクトをビューに渡すことは絶対に問題ないと思います。

考慮すべきもう1つの重要なことは、セキュリティ/検証です。暗黙のMVCマッピングメカニズムと完全なドメインモデルを使用する場合、悪意のあるユーザーが、データベースに保存したくない値をコントローラーに送信する可能性があります。別のビューモデルクラスを使用するには、明示的なマッピング手順が必要です。この手順では、ドメインモデルにマッピングするビューモデル（=ユーザーが入力したデータ）のどのフィールドをシステムに明示的に通知する必要があります。

于 2012-09-05T10:55:57.310 に答える
1

ほとんどのものと同様に、それを行うには複数の方法があります。この場合、最終的には個人的な好みに帰着することがよくあります。

これと同じことをしているとき、メソッドに渡されているものが実際に有効かどうかをよく自問Userします。モデルの有効性を維持するために呼び出し元のコードに依存するのではなく、無効な状態を内部的に防ぐような方法でモデルを維持するのが好きです。

そのため、モデルを説明する情報を受け取るが、それ自体でモデルを完全に構築しないアクションがある場合があります。このような場合、私はビュー モデルを使用することを好みます。これにより、一貫性以外の理由がなければ、ビューモデルを全面的に使用することがよくあります。

ページ上の複数のモデルからの情報が必要な場合に特に便利です。2 つのモデルのようなものではなく、必要な情報を合成したビュー モデルを持つことは、私にとって単純Tupleにすっきりと感じます。これにより、ビューには役立つがビジネス オブジェクトを汚染する追加のプロパティ (計算フィールド、フラグなど) をビュー モデルに追加することもできます。(特定のフォーム要素、検証項目などの表示/非表示を切り替えます)

多くの場合、オブジェクト( User) とデータ構造( )の違いに注目することで、この種の質問に対する自分の好みを見つけることができますUserViewModel。従来のオブジェクト指向の意味では、Userはデータ メンバーを非表示にして機能のインターフェイスを提供する必要がありますが、 のようなフラットなデータ構造でUserViewModelはデータ メンバーが公開され、意味のある機能はありません。

ビューはデータ メンバーにバインドするだけなので、通常はドメイン オブジェクトではなくフラット ビュー モデルを使用します。

于 2012-09-05T10:56:56.157 に答える