エンティティvsモデルvsビューモデル
私はこの用語について少し時間を費やしました（MVCアプリケーションがないのであまり使用せず、通常は「モデル」と言います）が、これらはコンテキストによって異なることを意味すると感じています：
エンティティ
これは非常に簡単で、データベース内の1行です。
2）データベースに関連して、エンティティとは、データを保存できる個人、場所、または物のことです。
モデル
よく読みますが、これは基本的にエンティティの組み合わせであり、データの完全なセットを表します。たとえば、顧客のAddresslistモデルでは、エンティティの顧客、住所、そしておそらく個人を組み合わせます。
Viewmodel
ビューで見ることができるデータを正確に表すモデルであるMVVMまたはMVCパターンの用語。ビューモデルはアプリケーション層にあり、検証のための属性があります。 ASP.NET MVCモデルとViewModel
私の目には、これらの用語は少し冗長に見えます。Viewmodelは明らかに彼の用途を持っています。 EFからわかっているように、エンティティは単なる表現ですが、これら2つを組み合わせた場合、モデルはどこで使用されますか？
検証、セキュリティなどのようなものは、ViewModelで行わなければなりません。エンティティとビューモデルの間に別の抽象化を配置するために何百もの小さなテーブルがあるときにモデルを使用しますか？または、MVCとMVVMのエンティティとモデルに関して、通常は同じですか？
いつものように感謝と素敵な週末
マティアス
これらの用語を理解する人は少し異なりますが、これが私が理解する方法です。
エンティティ-ID（ID）を持つオブジェクト。通常はデータベースから取得されます。とてもシンプルなクラス。
モデル-任意のビジネスオブジェクト、これはちょっと広い用語です。エンティティ、プロジェクトで作成したカスタムクラスなどです。ビューでもコントローラー/ビューモデルでもないものはほとんどすべてです。
ViewModel-モデルとビューの間のある種のメディエーター。特定のビューとのやり取りのために、モデルとビュー間の通信を調整します。たとえば、検証を適用したり、より多くのモデルを1つの大きなオブジェクトに結合したりします。 ViewModelはイベント処理（たとえば、ボタンのマウスクリック）も担当するため、バインドするビュー（WPF）にコマンドを公開します。
「モデル」という用語はあいまいです。それらはすべてモデルです。
エンティティモデル
永続性の構造に非常に似ているクラス。 MemberEntityは、データベースのMembersテーブルの1つのメンバー行を表すモデルです。データベースに厳密には結び付けられていませんが、永続性のあるエンティティです。通常、「int MemberID」などの「ID」プロパティがあります。
ViewModel
ビュー/ UIの構造によく似たクラス。 MemberViewModelは、アプリケーションのフロントエンドのメンバービュー/ UIに表示される1つのメンバーを表すモデルです。 MV *パターンに厳密には結び付けられていません。
通知
...上記の2つのモデルは、アプリケーションの境界での通信を表します。つまり、通信（ユーザーイベントとプロトコル経由の通信）を受信してビジネスルールを開始するフロント境界（エントリポイント）。また、ビジネスルールからコマンドを取得して他のシステム（データベースや他のエンドポイントなど）との通信を開始するバックバウンダリー。
ドメインモデル
問題ドメインの一部を表すクラス。 MemberModelは、その作成と検証を担当します。サービスはモデルを取り込んで返すので、モデルは正しい構築と使用を検証する独自のビジネスロジックを担当します。 E.G .: UserNameなしで使用しようとするとMemberModelが壊れます。
ドメインサービス
ドメインサービスはエンティティモデルを取得し、それらをドメインモデルに変換します。これにより、これらのサービスはモデルと連携できます。エンティティが後方境界から入り、ドメインモデルへのシリアル化またはマッピングに失敗した場合、data is badという赤いフラグがあります。
ドメインサービスは、ドメインモデルを取り、それらをエンティティにマッピングして、バックバウンダリから送信します。バック境界（DB/SDK？）がモデルの受け入れに失敗した場合、DB/SDKを修正する必要があります。
- 注：永続性は詳細であるため、エンティティはModelsに準拠しています。ドメインはシステムの王様であり、ハードウェアや永続性のテーブル構造ではありません。ドメインは決して間違っていません。
フロント境界はViewModelsを取り、それらをDomain Modelsに変換して、ドメインに渡すことができるようにします。 ViewModelがドメインモデルへのシリアル化またはマッピングに失敗した場合、view/json/xmlが不良であるという赤いフラグがあります。
ドメインサービスは、フロント境界にドメインモデルを返します。その後、フロント境界と通信するためにViewModelsにマッピングされます。ビュー/ UIがモデルの受け入れに失敗した場合、ビューを修正する必要があります。
- 注：ViewModelsはModelsに準拠しています。なぜなら消費者は詳細だからです。ドメインはシステムの王様であり、UIを使用するサブアプリやサブアプリではありません。ドメインは決して間違っていません。
ViewModelはエンティティを決して認識しません UI/Consumerは永続性が存在することさえ知らないためです。
コアビジネスロジックは、ViewModelまたはエンティティを認識すべきではありません。コアビジネスロジックは、ドメインモデルでのみ機能します。そのため、コントローラーとその近くのフロントエンドサービスが存在します。ドメインモデル<=> ViewModelsをマップするには。それが、SDKとその近くのバックエンドサービスが存在する理由でもあります。 DomainModels <=>エンティティをマップします。
システムが構築されると、ドメインとビジネスロジックが最初に構築されます（願わくはTDD）。次に、アダプターがビジネスロジックのフロントとバックに配置され、デリバリメカニズム（フロントエンド）と依存関係（サービス/永続性）（バックエンド）が決定されます。しかし、それらのフロントエンドとバックエンドは取り払われる可能性があり、コアビジネスロジックはまだ存在しています。
短いバージョン（TLDR;）：
エンティティ：データベースレコード。
ドメインモデル：ドメイン問題のオブジェクトを表すモデル固有のビジネスロジック（Google「値オブジェクト」）。
ViewModel：ビューのページ（またはセクション）。
私の理解では、モデルはここでは中心的な概念であり、解決される問題の理解を反映しています。エンティティは、モデルオブジェクトをデータベースに保存する方法を決定します。 Viewmodelsは、モデルのどの部分をエンドユーザーに表示するかを決定します。
これらの用語の定義は非常にあいまいです。さまざまな場所でさまざまな定義が見つかります。
Entity：エンティティは、データベースオブジェクトにレコードとして保存されたドメインオブジェクトの単一インスタンスを表します。テーブルの列として表すいくつかの属性があります。
Model：モデルは通常、問題またはドメイン空間に関連する実世界のオブジェクトを表します。プログラミングでは、オブジェクトを表すクラスを作成します。モデルと呼ばれるこれらのクラスには、いくつかのプロパティとメソッドがあります（オブジェクトの動作を定義します）。
ViewModel：ViewModelという用語は、[〜＃〜] mvvm [〜＃〜]（モデルビューViewModel）デザインパターン。ビューによってレンダリングされるデータが2つの異なるオブジェクトから取得される場合があります。このようなシナリオでは、ビューに必要なすべてのプロパティで構成されるモデルクラスを作成します。特定のビューで使用されるため、ドメインモデルではなく、ViewModelです。また、実世界のオブジェクトを表していません。
詳細については、私のブログ投稿を参照してください： Entity vs Model vs ViewModel vs DataModel