連載：ADO.NET Entity Framework入門 第5回　POCOによるエンティティ・クラス WINGSプロジェクト　土井 毅 著／山田 祥寛 監修 2010/11/05

Page1 Page2 Page3

　今回のテーマは「POCO」*1によるエンティティ・クラスの実装である。

*1 「Plain Old CLR Object」の略。特別なクラスやインターフェイスの継承／実装を行っていないプレーンな.NETクラス（のオブジェクト）のこと

　前回までに解説してきたとおり、Entity Frameworkは“概念モデルによるプログラミング”という、扱いやすいプログラミング・モデルを提供してきたが、同時にそれは、アプリケーションがEntity Frameworkという特定の技術に深く依存することも意味していた。データベースに直接アクセスする部分がEntity Frameworkに依存することには何ら問題はないが、実際の業務処理を行うビジネス・ロジック部分までがEntity Frameworkに依存するのは望ましいことではない。

　.NET Framework 4のEntity Frameworkの新機能である「POCOによるエンティティ・クラス」を用いることで、Entity Frameworkへの依存関係を、本当に必要な部分に限ることができる。また、一般にN層アーキテクチャなどと呼ばれる、アプリケーションを階層に分割するソフトウェア・アーキテクチャへの対応も容易になる。

　システムの階層化にはさまざまなアプローチがあるが、今回は図1のような3層アーキテクチャを扱うことにする。もちろん、ここで解説する概念の多くは、さらに多くの層を持つN層アーキテクチャにも適用可能である。

図1 3層アーキテクチャの例

　表1は、それぞれの層の役割および関連する技術などをまとめたものである。

概要 関連する技術、コンポーネントなど プレゼンテーション層 ユーザー・インターフェイスを提供する層 ネイティブ・アプリケーションUI、Webアプリケーション、RIAなど ビジネス層 システムの業務処理を行う層 業務処理対象のドメイン・オブジェクト、ビジネス・ロジックなど データ層 データソースやほかのサービスとのデータのやり取りを行う層。多くのケースではデータベースを中心とし、データの永続化処理を行う データベース・ミドルウェアやWebサービスへアクセスするためのクライアントなど

表1 3層アーキテクチャの分割例

　階層化を意識しないアプリケーションの場合、ユーザー・インターフェイスとデータベースがほぼ直結していたり、ビジネス・ロジックから直接データベースにアクセスしたりすることも少なくない。例えば、Visual StudioでWindowsアプリケーションやASP.NETアプリケーションを作成し、データ表示、編集用のコンポーネントを使用した場合などがそうである。

　しかし、一定以上の規模のシステムにおいては、階層化は不可避であり、それに対応する技術が求められていく。POCOによるエンティティ・クラスは、Entity FrameworkがN層アーキテクチャに対応するうえでも重要な機能である。その点を理解するに当たって、まずは「永続性非依存」という重要な原則について解説する。

• 今回作成するサンプルのダウンロード（ef4basic_5_sample.zip）

POCOと永続性非依存（Persistence Ignorance）原則

　前回までは、EDMからのエンティティ・クラスの自動生成を用いてサンプル実装を行ってきた。Visual Studioのサポートにより、ほとんど意識することなくエンティティ・クラスが生成される、手間のかからない方法である。

　しかし、自動生成されたエンティティ・クラスは、Entity Frameworkに深く依存する実装となってしまう欠点がある。リスト1は自動生成されたEntryエンティティ・クラスの定義の例であるが、エンティティ・クラスが「EntityObject」というクラスを継承し、さらにクラスやプロパティにいくつもの属性が付加されていることが分かる。

// Entryクラス定義。EntityObjectを継承 [EdmEntityTypeAttribute(NamespaceName="AddressBook", Name="Entry")] [Serializable()] [DataContractAttribute(IsReference=true)] public partial class Entry : EntityObject {   //IDプロパティ定義   [EdmScalarPropertyAttribute(EntityKeyProperty=true, IsNullable=false)]   [DataMemberAttribute()]   public global::System.Int32 ID ' Entryクラス定義。EntityObjectを継承 <EdmEntityTypeAttribute(NamespaceName:="AddressBook", Name:="Entry")> <Serializable()> <DataContractAttribute(IsReference:=True)> Public Partial Class Entry     Inherits EntityObject   'IDプロパティ定義   <EdmScalarPropertyAttribute(EntityKeyProperty:=true, IsNullable:=false)>   <DataMemberAttribute()>   Public Property ID() As Global.System.Int32

リスト1 自動生成されたEntryエンティティ・クラス定義（上：C#、下：VB）

EntityObjectを継承し、属性を付加している

　小さなサンプルにおいては、このようにエンティティ・クラスがEntity Frameworkに依存することに問題はないが、階層化されたシステムにおいては話が変わってくる。

　重要になるのは永続性非依存（Persistence Ignorance）と呼ばれる原則である。これは、永続性すなわちデータの永続化（保存、読込）は、直接処理を行う層のみが意識し、直接関与しないそれ以外の層は、永続化処理に依存しないようにする、という原則である*2。

*2 Persistence Ignoranceは「永続性無知」とも訳される。永続処理を行う層以外は、データがどうやって永続化されるかについて「無知である」「無知でいられる」の意。この場合の「無知」にはネガティブな意味はない。

　永続性非依存の原則を守ることにはさまざまなメリットがある。

　まず、アプリケーション内の役割分担が明確化されることである。データベースへの接続やデータの取得／保存処理、あるいはXMLファイルの読み書きやWebサービスへのアクセスなど、永続化処理にかかわる部分をデータ層にまとめ、業務処理を行うビジネス層は、データがどのように永続化されるかを意識せず、純粋に業務処理の実装に集中できる。

　また、ビジネス層は特定の永続化技術に依存していないため、データ層のみを書き換えれば、永続化技術を切り替えることも可能である。例えば、リレーショナル・データベースで永続化処理を行っていたアプリケーションを、XMLファイル、XMLデータベースやWebサービスなどのほかの永続化技術に切り替えるといった大きな方針変更があったとしても、データ層以外は基本的に書き換えの必要がない。

　さらに、付随的なメリットとしては、テストが容易になる点が挙げられる。例えばデータベースへの読み書きを含むアプリケーションの場合、テストにはデータベースへのテスト・データの投入など、さまざまな事前準備が必要となる。永続性非依存原則に沿ったアプリケーションの場合、ビジネス・ロジックは永続化技術に依存していないため、テスト・データをデータベースに投入しなくても、オブジェクトとして渡すだけでテストを行うことができる。

　こうした点をかんがみ、.NET Framework 4のEntity Frameworkから、POCOによるエンティティ・クラスがサポートされ、永続性非依存原則に沿ったアプリケーションの構築が可能となった。

INDEX
	ADO.NET Entity Framework入門
	第5回　POCOによるエンティティ・クラス
	1．POCOと永続性非依存（Persistence Ignorance）原則
	2．POCOによるエンティティ・クラスの作成／【コラム】T4テンプレート
	3．生成されたオブジェクト・コンテキスト・クラスの確認／【コラム】コード・ファースト

　

「ADO.NET Entity Framework入門」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）