POCOは何のために使用できますか？

Question

enttityフレームワークでPOCOに関する記事を読んだことがありますが、それでも私が使用できるものはまだ分かりません。 POCOはどのように私のプロジェクトに利益をもたらすことができますか？

Answer 1

"Plain Old Clr Object"のPOCO規格。これは、ORMアーキテクチャのスタイルを指し、データストアからデータを永続化およびロードするためのすべての作業は、オブジェクト自体に何が起こっているかを知ることなくシステムによって行われます。これは、ORMが完全にの平文をサポートできることを意味します。これは、ORMを念頭に置いて変更されていないオブジェクトです。 POCOの永続性をサポートするORMでは、クラスを特定のベースから継承したり、インターフェイスを実装したり、任意の属性を持つメソッドにタグ付けする必要はありません。

データアクセスオブジェクト（DAOとも呼ばれます）の完全な反対は、すべての記憶域がオブジェクト自体によって処理されるときです。それは、それ自体をシリアル化して格納する方法と、必要に応じてロードする方法を正確に認識します。この場合、オブジェクトは純粋にデータを転送するために使用されるべきであり、システムのビジネスロジックを表すべきではありません。

実際には、どちらか一方の端にこれらの2つの状況があります。多くのORMは中間のどこかに座っており、永続性はクラスの外部で処理する必要がありますが、しばしば、クラスに実装されているメタデータやインタフェースを必要とします。

EF（v1）はPOCOをサポートしていません。オブジェクトは、フレームワークによって永続化できるように、（プロパティ値の変更などの通知を提供するために）さまざまなインタフェースを実装する必要があります。私はaddon frameworksがEFにPOCOサポートを追加しようとしていると信じていますが、どれくらい成功しているのかわかりません。 EF in .net 4.0にはPOCOがサポートされます。

POCOは、懸念の強い分離を可能にするため、しばしば良好とみなされます。データオブジェクトを格納するために使用されるメカニズムについての知識が全くないように、データオブジェクトを定義することができます。 （したがって、将来的に異なるストレージメカニズムを簡単に切り替えることができます）。つまり、データオブジェクトを保存するために使用されるデータベース/フレームワークについて考慮してデータオブジェクトを設計する必要はありません。

Answer 2

POCOは単に "Plain Old CLR Object"です。これは単なる標準クラスです。標準クラスです。

EFでは、独自のクラス（EFによって直接生成されたものではない）をデータベースに格納するようにEFを構成できることを人々は指摘しています。

Answer 3

POCOは、アプリケーション内でデータを転送する（つまり、データレイヤーからUIレイヤーにデータを移動する）ように設計されたクラスです。また、アプリケーションの構造をデータベースのスキーマから切り離します。

小規模なプロジェクトではこれは大きな問題ではありませんが、プロジェクトが成長するにつれて（POCOをどのように設計するのか）オブジェクトモデルはデータベーススキーマから逸脱する傾向があります。

通常、.Netで使用されるその他の方法は、DataTablesとDataSetsです。通常、データは列名を使用して取得されます。これはあなたのデータベースの列名を結合します。データベース内で列名が変更されると、コードが破損します。

Answer 4

POCOは通常のクラスです。このコンテキストでは、データベースレイヤーで動作させるためのインターフェイスや基本クラスは追加されていません。

アドバンテージは 1）その特定のデータベースレイヤーに依存しないので、データベースレイヤー以外のものを変更することなく、より良いもの（つまりNHibernate）にスワップアウトすることができます。

2）クラスの単体テストを容易にします。

3）プロパティが変更されたときなどに通知するボイラープレートコードなし。ゲッターとセッターのみ。

Idealyドメインオブジェクトは、そのオブジェクトがいずれかのNHibernateのは、この時に非常に良い仕事をしていません

などの変更が追跡されるかまたはそれが保存されているか、それがロードされていますどのように言っていしなくても、ORMからロードされています唯一の要件は、すべてのプロパティ/メソッドを仮想化する必要があることです。これは、ハード依存性よりずっと優れています。