enttity フレームワークで POCO に関する記事をいくつか読みましたが、何に使用できるかまだわかりません。POCO は私のプロジェクトにどのようなメリットをもたらしますか?
4 に答える
「Plain Old Clr Object」の POCO 標準。これは、データストアからのデータの永続化とロードに関するすべての作業が、オブジェクト自体に何が起こっているかを知らずにシステムによって行われる ORM アーキテクチャのスタイルを指します。これは、ORM が、ORM を念頭に置いて変更されていない完全にプレーンなオブジェクトをサポートできることを意味します。POCO の永続性をサポートする ORM では、クラスを特定のベースから継承したり、インターフェイスを実装したり、メソッドに属性をタグ付けしたりする必要はありません。
これとは正反対 (Data Access Objects - または DAO とも呼ばれます) は、すべてのストレージがオブジェクト自体によって処理される場合です。オブジェクトは、オブジェクト自体をシリアル化して格納する方法と、必要に応じて自身をロードする方法を正確に認識しています。この場合、オブジェクトは純粋にデータを転送するために使用する必要があり、システムのビジネス ロジックを表すものではありません。
実際には、これはどちらかの端にこれら 2 つの状況があるスペクトルのようなものです。多くの ORM はその中間に位置し、永続化をクラスの外部で処理する必要がありますが、多くの場合、永続化を支援するために永続化されるクラスに実装されているいくつかのメタデータまたはインターフェイスも必要です。
EF (v1) は POCO をサポートしていません。オブジェクトは、フレームワークによって永続化できるようにするために、さまざまなインターフェイスを実装する必要があります (プロパティ値の変更などの通知を提供するため)。EF に POCO サポートを追加しようとするアドオン フレームワークがあると思いますが、それらがどれほど成功しているかはわかりません。.net 4.0のEFは POCO をサポートします。
POCO は、関心事の強力な分離を可能にするため、多くの場合、優れていると見なされます。データ オブジェクトを格納するために使用されるメカニズムの知識がまったくないように、データ オブジェクトを定義できます。(したがって、将来別のものにストレージメカニズムを簡単に切り替えることができます)。また、データ オブジェクトを格納するために使用されるデータベース/フレームワークを考慮してデータ オブジェクトを設計する必要がないことも意味します。
POCO は単なる「Plain Old CLR Object」です。それは単なる標準クラス、標準クラスです。
EF に関しては、(EF によって直接生成されない) 独自のクラスをデータベースに格納するように EF を構成できることを指しています。
POCO は単なる通常のクラスであり、(このコンテキストでは) データベース レイヤーで動作させるためのインターフェイスや基本クラスが追加されていません。
利点は次のとおりです。1) 特定のデータベース レイヤーに依存しないため、データベース レイヤー以外を変更することなく、より優れたレイヤー (つまり NHibernate) に交換できます。
2) クラスの単体テストが容易になります。
3) プロパティが変更されたときなどに通知するための定型コードはありません。単純なゲッターとセッターだけです。
理想的には、ドメイン オブジェクトは ORM から読み込まれます。そのオブジェクトは、読み込み方法、変更の追跡方法、保存方法などについて発言する必要はありません。
NHibernate はこれに関して非常にうまく機能します。唯一の要件は、すべてのプロパティ/メソッドを仮想化する必要があることです。これは、ハードな依存関係よりもはるかに優れています。
POCO は、アプリケーション内でデータを転送する (つまり、データ層から UI 層にデータを移動する) ように設計されたクラスです。また、アプリケーションの構造をデータベースのスキーマから切り離します。
小規模なプロジェクトでは、これは大したことではありませんが、プロジェクトが大きくなるにつれて、オブジェクト モデル (POCO の設計方法) がデータベース スキーマから逸脱する傾向があります。
.Net で通常使用されるその他のメソッドは、DataTables と DataSets です。通常、データは列名を使用して取得されます。これにより、データベース内の列名を結合できます。データベースで列名が変更されると、コードが壊れます。