33
例と一緒にMVCフレームワークに関してこれらの3つの概念とその違いを説明することはできますか？私にとっては、これらはほぼ同等に見え、それはいくつかの記事では互換的に使用されているように見えます。MVCに関するドメイン、モデル、エンティティの区別
A
答えて
18
用語が少し曖昧です。私は同意します。あなたが扱っているビジネスエリアを参照するには、ドメインを使用します。銀行や保険のようなもの、そうでないもの。それからあなたはドメインモデルを持っています。これらは、そのビジネスドメインで扱っているものです。ドメインの銀行口座、顧客、振込などがあります。クラス/ POJOまたは永続/具象バージョンのモデルの参照には、エンティティという用語を使用します。 。おそらく、あなたは用語MVCで、モデルが、具体的なことですが、それはウェブGUIで、いくつかのプレゼンテーションを表すために使用されるデータモデルを参照するようでそれが混入していないということです、ここで混乱何
上記の説明と一緒に。
28
「domain objects」、「ドメインエンティティ」、および「モデルオブジェクト」は、混乱する用語です。交換可能に通常使用されるが、ドメインエンティティおよびモデルオブジェクトは、active recordパターンのインスタンス（基本的には、追加されたストレージロジックを持つドメインオブジェクト）でもかまいません。
通常のドメインオブジェクトでは、ストレージロジックはありません。それはdata mappersによって処理されます。
モデル全体がアプリケーションレイヤー（MVCはそれとプレゼンテーションレイヤーで構成されている）であるため、「モデルオブジェクト」という用語はFowlerの書籍（詳細はPoEAAを参照）から来ており、混乱MVCの一部です。これには通常、servicesで扱われる「モデルオブジェクト」が含まれています（その画像では、モデルレイヤーはすべて3つの同心円でまとめられています）。
代わりに、「ドメインオブジェクト」という用語を使用することをお勧めします。
「ドメインエンティティ」（または「エンティティオブジェクト」）という用語は、通常、オブジェクトがストレージ構造（より頻繁にはデータベーステーブル）の直接的な表現であることを暗示している場合に使用されます。これらはまた、ほとんど常にアクティブなレコードの実装です。
P.S：あなたはまた、用語 "モデル"（複数）を見るであろういくつかの記事で。これは通常、MVCデザインパターンとは直接関係していません。これは、Railsのようなアーキテクチャーについて言及しています。「モデル」はアクティブなレコードで、コントローラに直接公開されます。
...これは記録のためにあなたに多くの
3
を混同しているかどうかわかりません。実際の目的では、ドメインとモデルは同じですが、エンティティはデータベースに格納するために使用されるドメイン/オブジェクトです。
このようなトピックを再説明しようとする人もいますが、いずれもキヤノンではありません。
違いは、Javaの世界ではドメインが多く使われていますが、C＃の世界ではモデルが使用されています（MSは彼の使用を奨励しますが）。
同じ概念では、Value Object（VO）はJavaの人々によって使用され、DTOはC＃の人々にとっては実質的に同じであっても使用されます。また、POJO（Java）vs POCO（C＃）、Packages（Java）vs NameSpace（C＃）、Setter and Getter（Java）vs Encapsulation（C＃）
1
ドメインとモデルはどちらもクラスです。どのようにクラスが使用されているのかは、それを分類してドメインまたはモデルフォルダに入れるべきかどうかを区別します。クラスがビュー内でのみ使用される場合は、モデルフォルダに配置します。クラスがデータベースオブジェクトにマップされている場合は、それをドメインフォルダに配置します。
0
Domainは、データベーステーブル、外部サービスオブジェクトなどのクラスです。したがって、プロジェクトを開発してディレクトリDomainを作成すると、その中にデータベースオブジェクトを配置します。そのようなクラスはエンティティであり、そのプロパティを持つCustomerクラスにすることができます。それはなぜエンティティであり、POCOではないのですか？それはその使用のためです。エンティティの内容はデータベースに読み書きできます。エンティティとして考えているので、あなたはそれをどこで使うことができるのか知っています。知識によって、あなたはそのエンティティを知っています。あなたはそれをその名前に入れません。今すぐモデルのために。この顧客を使用している場合は、使用したくないプロパティがあります。顧客は本当に単純なエンティティになることができます。しかし、あなたは複雑なものを持っていると言うことができます。あなたが使用しないたくさんのプロパティを持つWebサービスから読んだ人。次に、このエンティティを読むことができます（=シリアライゼーションで完全に行うことができます）。そして、このエンティティを使用してモデルを作成します。そのエンティティがモデルにデータをコピーするために使用される場合は、DTO（Data Transformation Object）とも呼ばれ、時にはCustomerDTOとして記述します。エンティティからモデルにデータをコピーするには、マッピングツールを使用できます。 Entityの名前がCustomerModelに変更されます。それでは、拡張モデルを使用します。そうでないと、何が何であるのかわからなくなるからです。このCustomerModelには他にもたくさんのプロパティがあります。これらのプロパティの中には、プロセスのプロパティ（顧客エンティティから来る必要はありません）があります。これらのプロパティのコンテンツは、他のサービスに由来します。 Customerから作成できるシンプルなものはFullnameで、Customerのいくつかのプロパティから構成されています。したがって、CustomerModelの塗りつぶしは複雑になる可能性があります。 CustomerModelを呼び出すためのコードをいわゆるFactoryに配置し、このCustomerFactoryを呼び出すことができます。