基本的には同じだという印象を受けました。モデルオブジェクトも同じですか？

現在、私のアーキテクチャでは、次のことがあります。

class Person 
{

    public string PersonId;        
    public string Name;
    public string Email;

    public static bool IsValidName() { /* logic here */ }
    public static bool IsValidEmail() { /* logic here */ }
}


class PersonService
{
    private PersonRepository pRepository;

    PersonService()
    {
        pRepository = new PersonRepository();
    }

    public bool IsExistingEmail(string email)
    {
        //calls repo method to see if email is in db
    }


    public Person GetPerson(email)
    {
        return pRepository.Get(email);
    }


    public void SavePerson(Person p)
    {
        if (Person.IsValidEmail(p.Email) && !IsExistingEmail(p.Email)
        {
            pRepository.Save(p);
        }
    }

}


class PersonRepository
{
    public void Save(Person p)
    {
        //save to db
    }

    public Person Get(string email)
    {
        //get from db
    }

    public bool IsExistingEmail(string email)
    {
        //see if email in db
    }

}

したがって、上記のクラスのどれありPOCO、Domain Object、Model object、entity？

私の（非標準の）レイマンの定義

• POCO-プレーンな古い％Insert_Your_Language％オブジェクト。ロジックが含まれていないタイプ。データをメモリに保存するだけです。通常、自動プロパティだけが表示され、フィールドやコンストラクターが表示されることもあります。
• Domain objectドメインに関連するクラスのインスタンス。私はおそらく、衛星オブジェクトまたはユーティリティオブジェクトをドメインオブジェクトから除外します。たとえば、ほとんどの場合、ドメインオブジェクトには、ログ、シリアル化、フォーマット、または暗号化する製品を特別に構築している場合を除き、ロギング、フォーマット、シリアル化、暗号化などは含まれません。 。
• Model objectと同じだと思いますDomain object。人々はこれを同じ意味で使用する傾向があります（私は間違っている可能性があります）
• Entity を持っているクラス id
• Repository一方の側からデータストレージ（データベース、データサービス、ORMなど）と、サービス、UI、ビジネスレイヤー、またはその他の要求機関と通信するクラス。通常、データ関連のもの（レプリケーション、接続プール、キー制約、トランザクションなど）をすべて隠し、データの操作を簡単にします。
• Service通常はパブリックAPIを介していくつかの機能を提供するソフトウェア。レイヤーに応じて、たとえば、RESTfulな自己完結型コンテナー、または必要なタイプの特定のインスタンスを見つけることができるクラスにすることができます。

元の回答

これらは、主に（分散）ドメイン駆動設計で使用される用語です。それらは同じではありません。モデルオブジェクトという用語は、ドメインオブジェクトの同義語として使用できます。

ドメインオブジェクト。ドメインの専門家にとって意味のある何かを表す、ビジネス固有の領域からのオブジェクト。ドメインオブジェクトは、主にエンティティと値オブジェクトによって表されます。一般的に言えば、ドメインレイヤーに存在するほとんどのオブジェクトはモデルに寄与し、ドメインオブジェクトです。

エンティティ。基本的にその属性ではなく、継続性とアイデンティティのスレッドによって定義されたオブジェクト。（それは意味しなければならない持っている同上）

POCO。複雑なロジックのない単純なオブジェクト。通常、いくつかのプロパティがあり、ORMで、またはデータ転送オブジェクトとして使用されます。

class Person-エンティティとPOCO、このクラスのインスタンスはドメインオブジェクトです
class PersonService-サービス
class PersonRepository-リポジトリ

基本的にそれは内部ロジックに帰着します

1. ドメインオブジェクトには、検証などのための内部ドメインロジックがあります。
2. モデルは基本的に軽いドメインオブジェクトであり、保持しているデータについては知っていますが、それがどのように使用されるかについては実際には何も知りません。
3. エンティティはデータを保持し、データがどこから来たのか、どこに保存、更新されるのかなどの内部知識を持っています
4. POCOはデータを保持しており、プロパティコレクション内のすべてのアイテムの合計値など、自分自身に関する内部知識を持っている場合があります。
5. DTOはすべての中で最も単純なアイテムであり、データを保持するだけでロジックはありません

それらはすべて基本的に同じ目的で使用されます、それはあなたがそれらをどれだけ賢くしたいかです

コードサンプルによると、Personクラスはドメインオブジェクトまたはモデルであり、他の2つはサービスとリポジトリです。ドメインオブジェクト、Pocos、モデル、dtosなどはメッセージのように使用され、あるレイヤーから次のレイヤーに渡されます。PersonServiceのようなサービスクラスはアプリケーションのレイヤーであり、PersonRepositoryのようなリポジトリクラスと同じです。全体像については、http：//bob-the-janitor.blogspot.com/2009/07/n-tier-design-revisit-part-1-over-view.htmlをご覧ください。この場合は、使用について説明しています。基本的にdtoであるデータエンティティ

それは機能の意味合いです。ドメインオブジェクトは、ロジック実装に固有のものであり、単純なPOCOよりも複雑な場合があります。エンティティには何かを表す意味合いがあり（通常は永続性メディアを参照）、POCOはクラスの単なる簡単な識別子です。モデルは、オブジェクトを表すために使用される単なる用語です（通常は状態を含み、通常はUIまたはDBを扱います）。

機能的な違いがあるわけではありません。それらは、何かをより厳密に説明するための単なる異なる用語です。レースカー、トラック、ファミリーセダンの違いのように。すべて自動車ですが、各用語はより説明的です。

上記の回答には、ドメインとモデルの適切な説明がすでにあります。

データベースコンテキストエンティティでは、エンティティ関係モデルERDのアイテムを意味しますます。（つまり、テーブルの行）

では、マイクロソフト-DOTNET-EntityFramework世界エンティティからロードされたデータ（ベース）コンテキストを使用してデータベースに保存することができ、オブジェクトを意味します。通常、エンティティはそのData（Base）Contextなしでは存在できません。（ユニット-）これらのクラスのビジネス機能のテストは困難です。

Pocos（プレーンな古いCommonRuntimeオブジェクト）は、PersistenceFramework（EntityFrameworkまたはNHibernate）がなくても存在できるため、テストがはるかに簡単です。

pocoという単語は、同じ理由でJavaの世界で作成されたpojo （プレーンオールドJavaオブジェクト）を応用したものです。

ドメインオブジェクトは、アプリケーションのドメインレイヤー内のエンティティです。Addressクラス。「モデル」は同じことを意味します-「ドメインモデル」のエンティティ。

POCO（プレーンオールドCLRオブジェクト）は、動作（メソッド）が定義されておらず、データ（プロパティ）のみが含まれているオブジェクトです。POCOは通常、レイヤー間でデータを伝送するためのDTO（データトランスポートオブジェクト）として使用され、データはドメインオブジェクト/エンティティにデータを入力するために一般的に使用されます。