私の 2 セントの価値については、モデルが有効な状態 (すべての検証基準を適用) であるか、そうでないかのいずれかです。特定の状況下で検証を適用したくない場合は、実際には別のモデル (実際には ViewModel) を使用する必要があると思います。
あなたの例ではRegisterViewModel
、サインアップ用とEditUserViewModel
詳細の変更用に別々に作成します。これらにはそれぞれ独自の検証があり、単一の責任があります。
多くの異なるビューで再利用するファット モデルを作成することは、ちょっとしたコードの匂いがします。私がそう考えるにはいくつかの理由があります。まず、ユーザー データとのすべてのやり取りに使用される単一のモデルがあるとします。次のようになります。
public class UserModel
{
public int UserId { get; set; }
public string Username { get; set; }
public string Password { get; set; }
public bool IsAdministrator { get; set; }
}
後で、サイトへの登録時に使用されたブラウザーを追跡することにしました。それをどこに追加しますか?それは実際にはユーザーとは何の関係もないので、UserModel
モデルに入るべきではありません。別のものを持っている場合はRegisterViewModel
、登録プロセスが変更されたときに、それが使用されている他の場所にどのように影響するかを気にせずに、必要に応じて変更できます.
たとえば、MVC の DefaultModelBinder で上記のモデルを使用していた場合、より深刻な問題が発生します。hereで説明されているように、フォームにフィールドがない場合でも、ユーザーは独自のリクエストを作成し、自分自身に管理者権限を付与することができますIsAdministrator
(一括割り当ての脆弱性を悪用することにより)。この場合も、プロパティを指定せずに別の ViewModel を使用するIsAdministrator
と、セキュリティ ホールの領域が減少します。
上記は一例ですが、ご理解いただければ幸いです。