POCO = Plain Old CLR (またはそれ以上: クラス) オブジェクト
DTO = データ転送オブジェクト
この投稿には違いがありますが、率直に言って、私が読んだブログのほとんどは、DTO の定義方法で POCO を説明しています。DTO は、アプリケーションのレイヤー間でデータを移動するために使用される単純なデータ コンテナーです。
POCO と DTO は同じものですか?
POCO は OOP の規則に従います。状態と動作を持つ必要があります (必須ではありません) 。POCO は、Martin Fowler [逸話はこちら]によって造られた POJO から来ています。彼は、フレームワークの重い EJB 実装を拒否することをよりセクシーにする方法として、POJO という用語を使用しました。POCO は、.Net の同じコンテキストで使用する必要があります。フレームワークにオブジェクトの設計を指示させないでください。
DTO の唯一の目的は状態を転送することであり、動作はありません。このパターンの使用例については、 Martin Fowlerによる DTO の説明を参照してください。
違いは次のとおりです。POCO は、プログラミング(古き良きオブジェクト指向プログラミング)へのアプローチを説明しています。DTO は、オブジェクトを使用して「データを転送する」ために使用されるパターンです。
POCO を DTO のように扱うことはできますが、そうすると貧血ドメイン モデルが作成されるリスクがあります。さらに、DTO はビジネス ドメインの真の構造を表すのではなく、データを転送するように設計する必要があるため、構造に不一致があります。この結果、DTO は実際のドメインよりもフラットになる傾向があります。
適度に複雑なドメインでは、ほとんどの場合、別のドメイン POCO を作成して DTO に変換する方が適切です。DDD (ドメイン駆動設計) は、分離を明確にする優れた構造である腐敗防止レイヤー(別のリンクはこちらですが、本を購入することをお勧めします) を定義します。
ブログ記事で自分の立場を述べたので、貢献するのはおそらく冗長ですが、その記事の最後の段落は次のように要約しています。
結論として、POCO を愛することを学び、POCO が DTO と同じものであるという誤った情報を広めないようにしてください。DTO は、アプリケーションのレイヤー間でデータを移動するために使用される単純なデータ コンテナーです。POCO は、Persistence Ignorant (get または save メソッドなし) であるという 1 つの要件を持つ本格的なビジネス オブジェクトです。最後に、Jimmy Nilsson の本をまだ読んでいない場合は、地元の大学の書庫から手に取ってください。C# の例があり、とても読みやすいです。
ところで、Patrick 私は POCO をライフスタイルの記事として読みましたが、それは素晴らしい記事であることに完全に同意します。これは実際には、私が推奨したジミー・ニルソンの本の一部です。オンラインで入手できるとは知りませんでした。彼の本は、POCO / DTO / Repository / およびその他の DDD 開発プラクティスで見つけた最高の情報源です。
POCO は、外部フレームワークに依存しない単なるオブジェクトです。プレーンです。
POCO に動作があるかどうかは重要ではありません。
DTO は、ドメイン オブジェクトと同様に POCO である場合があります (通常、動作が豊富です)。
通常、DTO はシステムの境界で終了するため、シリアル化の目的で外部フレームワーク (属性など) に依存する可能性が高くなります。
典型的な Onion スタイルのアーキテクチャ (広範な DDD アプローチでよく使用される) では、ドメイン層が中心に配置されるため、この時点でそのオブジェクトはその層の外部に依存するべきではありません。
DTO の主な使用例は、Web サービスからデータを返す場合です。この場合、POCO と DTO は同等です。POCO の動作は、Web サービスから返されるときに削除されるため、動作があるかどうかは問題ではありません。
DTO オブジェクトは、データをさまざまなソースからのオブジェクトに逆シリアル化するために使用されます。これらのオブジェクトはモデル (POCO) オブジェクトではありません。これらのオブジェクトをモデル (POCO) オブジェクトに変換する必要があります。変換は、ほとんどがコピー操作です。これらの POCO オブジェクトが内部ソースの場合はソースから直接入力できますが、外部ソースの場合はアドバイスできません。外部ソースには、使用するスキーマの説明を含む API があります。要求データを DTO にロードしてから、POCO に変換する方がはるかに簡単です。はい、追加の手順ですが、理由があります。ルールは、ソースからオブジェクトにデータをロードすることです。JSONでもXMLでもかまいません。ロードされたら、そのデータをモデルで必要なものに変換します。したがって、ほとんどの場合、DTO は外部ソースのオブジェクト イメージです。
一般的なルールは次のとおりです。DTO==悪であり、過度に設計されたソフトウェアの指標です。ポコ==いいね。「エンタープライズ」パターンは、Java EE の世界の多くの人々の頭脳を破壊してきました。.NET ランドで間違いを繰り返さないでください。
それらを DTO とさえ呼ばないでください。彼らはモデル....ピリオドと呼ばれています。モデルには動作がありません。誰がこの馬鹿げた用語 DTO を思いついたのかはわかりませんが、それは .NET のものであるに違いありません。MVC のビュー モデルについて考えてみてください。同じダム ** のことです。モデルは、サーバー側のレイヤー間またはワイヤ期間にわたって状態を転送するために使用されます。それらはすべてモデルです。データ付きのプロパティ。これらは、ワイヤーの上を通過するモデルです。モデル、モデル モデル。それでおしまい。
DTO というばかげた用語が私たちの語彙から消えてくれればいいのにと思います。