POCO = Plain Old CLR（またはそれ以上：クラス）オブジェクト
DTO =データ転送オブジェクト
この投稿には違いがありますが、率直に言って、私が読んだほとんどのブログでは、DTOの定義方法についてPOCOについて説明しています。DTOは、アプリケーションのレイヤー間でデータを移動するために使用される単純なデータコンテナーです。
POCOとDTOは同じものですか？
回答:
POCOはOOPのルールに従います。状態と動作が必要です（必須ではありません）。POCOは、Martin Fowler [ 逸話はこちら ] によって造られたPOJOから来ています。彼はPOJOという用語を、フレームワークの重いEJB実装を拒否することをよりセクシーにする方法として使用しました。POCOは.Netの同じコンテキストで使用する必要があります。フレームワークにオブジェクトの設計を指示させないでください。
DTOの唯一の目的は状態を転送することであり、動作はありません。このパターンの使用例については、 Martin FowlerによるDTOの説明を参照してください。
違いは次のとおりです。POCOはプログラミング（古き良きオブジェクト指向プログラミング）へのアプローチを説明します。DTOは、オブジェクトを使用して「データを転送」するために使用されるパターンです。
POCOをDTOのように扱うことはできますが、そうする場合は貧血ドメインモデルを作成するリスクがあります。さらに、DTOはビジネスドメインの真の構造を表すのではなく、データを転送するように設計する必要があるため、構造に不一致があります。この結果、DTOは実際のドメインよりもフラットになる傾向があります。
合理的な複雑さのドメインでは、ほとんどの場合、個別のドメインPOCOを作成し、それらをDTOに変換する方がベターです。DDD（ドメイン主導の設計）は、汚職防止レイヤー（ここに別のリンクがありますが、本を購入することをお勧めします）を定義します。これは、分離を明確にする優れた構造です。
ブログの記事で自分の立場をすでに述べたので、貢献することはおそらく冗長ですが、その記事の最後の段落では、次のように要約しています。
したがって、結論として、POCOを愛することを学び、DCOと同じものであるという誤った情報を広めないようにしてください。DTOは、アプリケーションのレイヤー間でデータを移動するために使用される単純なデータコンテナーです。POCOは完全なビジネスオブジェクトであり、永続性を無視する（getまたはsaveメソッドを使用しない）ことが1つの要件です。最後に、Jimmy Nilssonの本をまだチェックアウトしていない場合は、地元の大学の本から取り出してください。C＃の例があり、読みやすくなっています。
ところで、パトリック私はPOCOをライフスタイルの記事として読みました、そして私は完全に同意します、それは素晴らしい記事です。それは実際に私が推薦したジミー・ニルソンの本のセクションです。私はそれがオンラインで利用可能であることを知りませんでした。彼の本は、私がPOCO / DTO /リポジトリ/およびその他のDDD開発プラクティスで見つけた情報の最高の情報源です。
DTOはPOCOになることができると思います。DTOはオブジェクトの使用方法に関するものであり、POCOはオブジェクトのスタイルに関するものです（アーキテクチャの概念から切り離されています）。
POCOがDTOとは異なる例の1つは、ドメインモデル/ビジネスロジックモデル内のPOCOについて話しているときです。これは、問題のドメインを表す適切なOO表現です。アプリケーション全体でPOCOを使用できますが、知識が漏洩するなどの望ましくない副作用が生じる可能性があります。DTOは、たとえば、UIが通信するサービスレイヤーから使用されます。DTOはデータのフラットな表現であり、UIにデータを提供し、変更をサービスレイヤーに通信するためにのみ使用されます。サービス層は、DTOの双方向のPOCOドメインオブジェクトへのマッピングを担当します。
更新 Martin Fowler は、このアプローチは取るに足らない道であり、ドメイン層とユーザーインターフェースの間に大きな不一致がある場合にのみ取られるべきであると述べました。
DTOの主な使用例は、Webサービスからデータを返すことです。この場合、POCOとDTOは同等です。POCOの動作は、Webサービスから返されるときに削除されるため、動作があるかどうかは問題ではありません。
一般的なルールは次のとおりです。DTO==悪であり、過剰に設計されたソフトウェアの指標。POCO ==良い。「エンタープライズ」パターンは、Java EEの世界で多くの人々の頭脳を破壊しました。.NETランドで間違いを繰り返さないでください。
DTOクラスは、さまざまなソースからのデータをシリアライズ/デシリアライズするために使用されます。ソースからオブジェクトを逆シリアル化する場合、それがどの外部ソースであるかは問題ではありません。サービス、ファイル、データベースなどです。その一部のみを使用したいが、そのデータを簡単に逆シリアル化する方法が必要な場合オブジェクト。その後、そのデータを使用するXModelにコピーします。シリアライザは、DTOオブジェクトをロードするための美しいテクノロジーです。どうして？オブジェクトをロード（非直列化）するために必要な関数は1つだけです。
TL; DR：
DTOは、状態転送のパターンを記述します。POCOは何も記述しません。これは、OOPでの「オブジェクト」の別の言い方です。それはPOJO（Java）から来たもので、Martin Fowlerによって造られたもので、Martin Fowlerは、文字通り 'object'のより奇妙な名前として説明しています。'object 'はそれほどセクシーではないからです。
DTOは、関係するレイヤー間で状態を転送するために使用されるオブジェクトパターンです。それらは、その振る舞いが状態を変化させない限り、振る舞いを持つことができます（つまり、技術的にはpocoになることができます）。たとえば、それ自体をシリアル化するメソッドがあるとします。
POCOはプレーンオブジェクトですが、「プレーン」が意味するのは、特別なものではないということです。これは、暗黙のパターンのないCLRオブジェクトであることを意味します。総称。他のフレームワークで動作するように作られていません。[JsonProperty]たとえば、POCOにEFデコレーションがそのプロパティ全体にある場合、それはPOCOではないと主張します。
ここで、比較するさまざまな種類のオブジェクトパターンの例をいくつか示します。
これらはすべて単なるオブジェクトですが、ほとんどがパターンに関連付けられていることに注意してください。したがって、それらを「オブジェクト」と呼ぶか、その意図についてより具体的にして、それが何であるかによってそれを呼び出すことができます。これもデザインパターンがある理由です。いくつかの作品で複雑な概念を説明します。DTOはパターンです。集約ルートはパターンであり、ビューモデルはパターンです（MVCおよびMVVMなど）。POCOはパターンではありません。
POCOはパターンを記述しません。これは、OOPでクラス/オブジェクトを参照するための別の方法です。それを抽象的な概念と考えてください。彼らは何かを指すことができます。IMO、一方向の関係はありますが、オブジェクトが1つの目的しか果たせなくなるポイントに到達すると、POCOではなくなります。たとえば、あるフレームワークで機能するようにクラスを装飾でマークアップすると、POCOではなくなります。したがって：
2つを区別するポイントは、パターンを明確にして一貫性を保ち、懸念を越えて密結合に至らないようにすることです。たとえば、状態を変更するメソッドを持つビジネスオブジェクトがあり、SQL ServerとJsonPropertyに保存するためのEFデコレーションで地獄に装飾されているため、APIエンドポイント経由で送信できるようになっているとします。そのオブジェクトは変更に耐性がなく、プロパティのバリアント（例：UserId、UserPk、UserKey、UserGuidなど）が散らばっていて、DBに保存されないようにマークされているものと、シリアル化されないようにマークされているものがあります。 APIエンドポイントでのJSON）。
ですから、何かがDTOだと言ったら、状態を移動する以外の目的でそれが使用されていないことを確認します。ビューモデルであると私に言った場合は、おそらくデータベースに保存されていないことを確認します。ドメインモデルだと言った場合は、ドメイン外の依存関係がないことを確認します。しかし、POCOであると私に言った場合、実際にはあまり私に話さないでしょう。
それらをDTOと呼ばないでください。それらはモデルと呼ばれています....期間。モデルに動作はありません。だれがこのばかげた用語のDTOを思いついたのかはわかりませんが、.NETである必要があります。MVCのビューモデルについて考えてみてください。これは同じダム**のことです。モデルは、サーバー側または回線期間にわたってレイヤー間で状態を転送するために使用されます。これらはすべてモデルです。データを持つプロパティ。これらは、ワイヤーを介して渡すモデルです。モデル、モデルモデル。それでおしまい。
ばかげたDTOが私たちの語彙から消えてくれることを願っています。