Visual Studio 2010 EF4 POCO Part1

  • Article

今日から３回に渡ってEF4におけるPersistence Ignorance and POCOについて解説します。

現行のEF v1はエンティティクラスにいくつかの制限事項がありました。

例えばエンティティクラスがEntityObjectのサブクラスであったり、IPOCO(IEntityWithKey, IEntityWithChangeTracker 、IEntityWithRelationships)の実装が必要になることです。このためドメインクラスはEFに依存した実装になります。

ここで、Patterns and Practicesの3 層サービス アプリケーションで定義されているドメイン層におけるビジネスエンティティを確認してみましょう。

ビジネス エンティティはデータ コンテナで、特定のデータ表現形式の詳細をカプセル化して表示されないようにします。たとえば、あるビジネスエンティティでは、リレーショナル データベースから取得したレコードセットがあらかじめカプセル化されるとします。その後、そのビジネス エンティティが XML ドキュメントをラップするように変更されても、アプリケーションの他の部分への影響を最小限に抑えることができます。

ビジネス コンポーネントおよびビジネス ワークフロー コンポーネントは、独立したビジネスエンティティ コンポーネントと対話することも、ビジネス エンティティを使用して独自の状況を設定してから、ビジネス エンティティを破棄することもできます。多くの場合、ビジネスエンティティは DTO (データ転送オブジェクト: Data Transfer Objects の略) [Fowler03] として使用されます。データ アクセスコンポーネントによって、データベース固有の構造ではなくビジネス エンティティが返されることもよくあります。これによって、データベース固有の詳細をデータ層に分離するのが非常に容易になります。

EFv1で利用できるデータソースはRDBという制限があります。そのため、例えば上記のようにデータソースがXMLに変更された場合、EFは利用できなくなってしまいます。ドメイン層の実装でEFのエンティティクラスを直接利用していた場合、大幅な修正が必要になるのは容易に想像できるでしょう。EFv1では、この点がPersistence Ignorance（永続化インフラに非依存）に反していました。

EF4ではPOCO(Plain Old CLR Objects)が導入されることで、この様な問題が大幅に改善される予定です。具体的にはEF4では以下のようなエンティティクラス（POCO）を用いた実装が可能になります。

    public class Customer

    {

        public string CustomerID { get; set; }

        public string ContactName { get; set; }

        public string City { get; set; }

        public List<Order> Orders { get; set; }

    }

    public class Order

    {

        public int OrderID { get; set; }

        public Customer Customer { get; set; }

        public DateTime OrderDate { get; set; }

    }

ただし、POCOを利用した実装ではEF4の機能がフルで利用できるわけではなく、いくつか機能制限が入ってくると思います。例えば、下記の事項はみなさんも気になる点ではないでしょうか。

・リレーションシップナビゲーション

・Change Tracking

・遅延ロード

・etc

今後、この辺りも解説して行きたいと思います。