ドメイン モデルをビュー モデルとして使用するのはよくないことはわかっています。ドメイン モデルに IsAdmin というプロパティがあり、ユーザーを作成するための Create コントローラー アクションがある場合、ビューでそのようなテキスト フィールドを公開していなくても、誰かがフォームを変更して IsAdmin=true フォーム値を POST させることができます。モデル バインディングを使用している場合、ドメイン モデルをコミットすると、その人は管理者になります。したがって、解決策は、ビュー モデルで必要なプロパティだけを公開し、AutoMapper などのツールを使用して、返されるビュー モデル オブジェクトのプロパティ値をドメイン モデル オブジェクトのプロパティ値にマップすることです。ただし、クラスの bind 属性を使用して、モデル バインダーにバインドするプロパティとバインドしないプロパティを指示できると読みました。では、本質的に同じものを表す 2 つの別々のクラス (ドメイン モデルとビュー モデル) を作成し、それらをマップする際にオーバーヘッドを発生させる本当の理由は何でしょうか。これはコード編成の問題ですか。そうであれば、どのようなメリットがありますか。
編集
ドメイン モデルとは別のビュー モデルが必要な最も重要な理由の 1 つは、複雑な UI を管理するために MVVM パターン (Martin Fowler の PM パターンに基づく) を実装する必要があることです。
ベストアンサー1
ドメイン モデルでは必要なフィールドを 85% 実現できましたが、ビューに必要な値を 100% カバーできたことはありませんでした。特に、権限や、ユーザーがビューの特定の部分にアクセスできるかどうかについてはそうです。
私が従おうとしている設計コンセプトは、ビューにできるだけロジックを少なくすることです。つまり、ビューモデルに「CanViewThisField」や「CanEditThisField」のようなフィールドがあるということです。MVCを使い始めた当初は、ドメインモデルをビューモデルにしていましたが、ビューをすっきりさせるためにフィールドを1つか2つ追加する必要があるという状況に常に遭遇していました。それ以来、私はビューモデル/モデルビルダールートは私にとっては素晴らしく機能しました。コードと格闘する必要はなくなり、ドメイン モデルに影響を与えることなく、必要に応じてビュー モデルを強化できるようになりました。