そのため、私のプログラミングのバックグラウンドは非常に独学で散発的です。私は MVC4 プロジェクトに取り組んでおり、機能だけでなくベスト プラクティスに集中しようとしています。
プロジェクトの一般的な意味は、レポート ジェネレーターです。そのため、ドメイン モデルとビュー モデルが正確に何であるか、および CodeFirst Entity Framework で使用されるモデルとどのように関連しているかを理解しようとしています。どんなヒントでも大歓迎です。
私の理解では、Report オブジェクトに複数のプロパティがあるとしますが、ビューではユーザーが特定のプロパティのみを編集できるようにしたい場合、ViewModel は Report オブジェクトとユーザー入力の間でマップされるものになりますか?
あなたは正しい考えを持っているようですね。AViewModelは、ドメイン エンティティのビュー表現です。これは、モデルに入ってくるデータと出ていくデータの両方に適用できます。
ただし、余分なレイヤー (およびマッピング) により、コードの複雑さも増します。ここで、ビュー モデル クラス、マッパー クラス、およびドメイン エンティティ (EF) が必要になります。したがって、この余分なレイヤーなしで必要なものを構築できる場合は、シンプルに保ちます。ドメイン モデルとドメイン モデリングは、非常に複雑なビジネス ドメインにのみ使用する必要があります。
はい、あなたの理解は正しいです。
ビュー モデルは、ビューで使用されるデータ オブジェクトです。一部のデータをユーザーに表示したり、ユーザーからデータを収集したりするために必要なプロパティが含まれています。これらのプロパティは必ずしもデータだけではありません。たとえば、入力フォームの任意のフィールドを有効にするか無効にするかを制御するために使用するいくつかのプロパティを使用できます。
一方、ドメインモデルは、ロジックと永続性に使用されるオブジェクトです。ここでも、永続化されたプロパティのみが含まれているとは限りません。永続化されたプロパティから計算された他のプロパティが存在する可能性があり、プロパティの上で動作するメソッドも存在する可能性があります。
一部の非常に単純なシナリオでは、ビュー モデルとドメイン モデルを同じオブジェクトで表すことができます。
これは私がいくつかの例で見たものであり、ここ数年使用して快適に感じているものであり、最近の仕事に就いたときに既存の MVC チームによってすでに使用されていたパターンでもありました。
基本的にエンティティ フレームワーク、または使用している ORM にはエンティティ クラスがあります。これらは、単純な POCO か、いくつかの ORM を備えたより重いものです。目標は、エンティティ間の関係が現実に非常に似ていることであり、そのため、それらはある意味で「ドメイン モデル」です。いずれにせよ、子/親オブジェクトからプロパティをフラット化するか、前述のように特定のフィールドのみを表示する必要があることがよくわかります。
多くの場合、ビュー モデルに追加のフィールドも必要になります。たとえば、ドロップダウン リストのオプションは、エンティティの一部ではないためです (選択されている項目を示す外部キーのみがエンティティにあり、ユーザーが選択できる項目のリストはありません)。
したがって、ビューが EF エンティティの @model を使用できるほど単純でない限り、多くの場合、ViewModel(VM) クラスが必要になることがあります。ビューごとに異なる VM を使用する人もいます。私は個人的に VM を再利用しようとしています。通常、スペースが限られている選択リストやインデックスなどに適したいくつかのフィールドである PersonSummaryViewModel と、重要なフィールドのみを表示する PersonViewModel と、エンティティのすべてのフィールドである PersonViewModel と、ドロップダウン リストのアイテムのフィールドです。 (ただし、読み取り専用ページで使用すると、それらは単に null のままになります)。
個人的には、PersonVM と PersonSummaryVM に名前を付けるのが好きですが、PersonViewModel のより冗長な名前を好む人もいます。EF はエンティティに Person などの名前を付けますが、他の ORM フレームワークではすべてのクラスに Entity の接尾辞を付けているので、PersonEntity. 個人的には Entity サフィックスが好きになりました。
データベースが適切に設計されている場合、エンティティ クラスはドメイン モデルと見なされるものに非常に近い可能性があります。
データを取得するために呼び出す静的メソッドを公開するクラスがあります。コントローラーにはデータベース コードがほとんどまたはまったく含まれておらず、その代わりにすべて、データベースのクエリを担当する PersonModelFactory.GetList()、PersonModelFactory.GetSingle(int id)、.Save(PersonVM person) などの静的メソッドにあります。エンティティからビュー モデルにデータを入力し、ビュー モデルを返します。これらのメソッドは、特定の検証 (ビュー モデルのデータ注釈で実行できる基本的なことを超えて) も実行し、その他のビジネス ロジックも実行します。そこには' これらのメソッドを非常に再利用可能にすることを目的としたインターフェイスとジェネリック パラメーターを含む実装の詳細について説明しますが、この記事の範囲では少し複雑です。実際にこれらのクラスを Web フォームと MVC の両方からうまく再利用したので、再利用可能性が証明されました。DB アクセス、マッピング、およびビジネス ロジック/検証が同じレイヤーで行われるという事実を好まない人もいますが、検証がパスしない限り DB の変更は発生しないため、これらがアトミックであることが重要であると感じました。相互依存。
おそらく、MVC でデータベース アクセス レイヤーに「リポジトリ パターン」を使用する方が一般的であり、MVC がこれらのクラスを生成するための足場さえあります。ただし、これらは通常、マッピングやビジネス ロジックを処理しません。
いずれにせよ、主な目標は、再利用して、コントローラー アクションの乱雑さを最小限に抑えることです。前述の因子パターンを採用する前に、コントローラーが雑然としていることに気付きました。アクション間でコードを再利用する機会があったため、コントローラーにプライベート メソッドを作成していました。私が所属しているチームが現在使用しているファクトリー パターンが本当に気に入っています。
人々がビュー モデルとリポジトリを使用する方法の多くのバリエーションを確実に見つけることができます。
MVC のコンテキストで「ドメイン モデル」について具体的に述べている記事や例を見た記憶がありません。IMO ドメイン モデリングは要件収集プロセスの一部であり、データベース/エンティティ フレームワークの設計には、これらの調査結果が反映されます。時間/リソース/複雑さの制限を考えると、ドメイン モデルを単純化できます。ドメイン言語などを扱うフレームワークがありますが、そうでないものはあまり一般的ではないと思います。
ORM が存在する前は、データベース レイヤー (SQL を実行するコマンド オブジェクトで構成される) の間で、多くの場合 POCO である "ビジネス オブジェクト" に手動でマッピングを行う人々がいました。検証/ロジックが何らかの形で組み込まれています。現在、人々が「ビジネス オブジェクト」について話しているのを聞くことはほとんどありません。なぜなら、そのレイヤーが果たす目的はほとんど EF に置き換えられており、ビジネス ロジックはコントローラー アクションまたは他のサービス レイヤーのいずれかにあるからです。
何年にもわたって、「ビュー モデル」、「ビジネス モデル」、「エンティティ」、および「ドメイン モデル」が人によって異なるということは確かです。