POCOの説明
POCO（Plain Old CLR Object）について（例を挙げて）しっかりと説明できる人はいないかと思います。 ウィキペディアで簡単な説明 を見つけましたが、確かな説明はありません。
それらをPOCOsと呼ぶ代わりに、私はそれらを永続性の無知なオブジェクトと呼ぶことを好みます。
彼らの仕事は単純なので、彼らは彼らが何のために使われているのか、彼らがどのように使われているのかを気にする必要はありません。
個人的には、POCOは、単純なプロパティを持つパブリッククラスの単なる流行語（Web 2.0のように-私はそれを始めないでください）だと思います。
私は常にこれらのタイプのオブジェクトを使用してビジネスの状態を保持してきました。
POCOの主な利点は、リポジトリパターン、ORM、依存性注入などを使い始めたときに実際に見られます。
言い換えれば、どこか（db、Webサービスなど）からデータをプルバックするORM（たとえばEF）を作成し、次にプロジェクトこのデータをオブジェクト（ POCO）。
これらのオブジェクトは、アプリスタックをさらに下ってサービスレイヤーに渡され、次にWeb層に渡されます。
その後、ある日nHibernateに切り替えることにした場合、POCOに触れる必要はまったくなく、変更する必要があるのはORMだけです。
したがって、「永続性を知らない」という用語は、何に使用されているのか、どのように使用されているのかを気にしません。
要約すると、長所は次のとおりです。
- データのシンプルなストレージメカニズムを可能にし、シリアル化/レイヤーの受け渡しを簡素化します
- 依存性注入、リポジトリパターン、ORMと密接に関連しています。柔軟性。
- 最小限の複雑さと他のレイヤーへの依存。 （上位層はPOCOのみを考慮し、POCOは何も考慮しません）。疎結合
- シンプルなテスト容易性（ドメインテストにスタブは必要ありません）。
お役に立てば幸いです。
POCOの使用を計画しているコンテキストなど、詳細を提供する必要があります。ただし、基本的な考え方は、必要なデータ/コードのみを含む単純なオブジェクトを作成することです。これらのオブジェクトには、アノテーション、追加のメソッド、基本クラスなど、フレームワークで必要となる可能性のある「手荷物」は含まれません。