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

■生成されたオブジェクト・コンテキスト・クラスの確認

　オブジェクト・コンテキストは、データベースとの永続化処理を担当する、3層アーキテクチャでいえばデータ層で使用するコードである。

　そのため、自動生成されるオブジェクト・コンテキストであるAddressBookContainerクラスの定義は、これまでと同様、Entity Frameworkに依存した実装が行われている（リスト3）。

// Entity Frameworkのコンポーネントをusing using System.Data.EntityClient; // ObjectContextクラスを継承 public partial class AddressBookContainer : ObjectContext ' Entity FrameworkのコンポーネントをImports Imports System.Data.EntityClient ' ObjectContextクラスを継承 Partial Public Class AddressBookContainer     Inherits ObjectContext

リスト3 オブジェクト・コンテキスト・クラス（上：Model1.context.cs、下：Model1.context.vb）

オブジェクト・コンテキストはデータ層のため、Entity Frameworkに依存する。

　なお、POCO Entity Generatorで生成されたオブジェクト・コンテキストは、Visual Studio 2010標準で生成されるオブジェクト・コンテキストよりも定義されているメソッドが少ないようである。

　例えば、前回までEntryエンティティをデータベースに保存するために用いていたAddToEntriesメソッドは、今回生成されたオブジェクト・コンテキストでは定義されていない。そのため、保存処理部分ではリスト4のように一部のコードを修正する必要がある*3。

*3 なお、定義がなくなったAddToEntriesメソッドなどは、コード中のコメントによれば非推奨メソッドとなっており、今回のようにAddObjectメソッドを呼び出すよう推奨されている。

// Entryエンティティをデータベースに追加 // container.AddToEntries(entry1); // AddToEntriesメソッド定義がなくなったので、 // AddObjectメソッドに切り替え↓ container.AddObject("Entries", entry1); // 変更内容を保存 container.SaveChanges(); ' Entryエンティティをデータベースに追加 ' container.AddToEntries(entry1); ' AddToEntriesメソッド定義がなくなったので、 ' AddObjectメソッドに切り替え↓ container.AddObject("Entries", entry1) ' 変更内容を保存 container.SaveChanges()

リスト4 データ保存の際のコードの修正

　こうしたわずかな変更を除き、基本的にエンティティ・クラスを使用するコードに修正は必要ない。これまで作成してきたサンプルの実行結果も、まったく同じとなるため、ここでは割愛する。

　今回のサンプルでは、ビジネス・ロジックからオブジェクト・コンテキストを直接呼び出す個所も残っており、3層アーキテクチャに基づく分割は行っていない。しかし、POCO化によりエンティティ・クラスからEntity Frameworkへの依存が除去されたことに注目しておきたい。

　例えば永続化処理をデータベースではなく、XMLファイルに行いたい、という場合においても、エンティティ・クラスは永続化処理に依存していないため、コードの修正個所を狭い範囲に留められるだろう。

【コラム】「コード・ファースト」開発スタイルのサポート 　Entity Framework 4における、POCOによるエンティティ・クラスのサポートは「コード・ファースト」と呼ばれる新たな開発スタイルへの扉を開いたようだ。 　詳細は「Entity Framework 4でコード・ファースト開発」を参考にしてほしいが、EDMを明示的に作成することなく、POCOによるエンティティ・クラス定義と、非常に簡潔なコンテキスト・クラスを作成するだけで、設定ファイルすらも必要としないデータベースの永続化処理が完結している。Ruby on Railsなどのフレームワークで採用されている「設定に勝る規約（convention over configuration：CoC）」の思想が取り入れられているようだ。 　この記事によれば、.NET Framework 3.5からサポートされていた「データベース・ファースト」（本連載では第4回でデータベースからのリバースとして解説）、.NET Framework 4でサポートされた「モデル・ファースト」に加え、よりコード中心の開発スタイルとして「コード・ファースト」が追加された、という位置付けになるようだ。ただ、このコード・ファーストという開発スタイルが、Entity Frameworkが当初より目標としてきた、概念モデルによるプログラミング、という思想とどのように折り合いを付けていくのかは、まだ未知数である。 　記事を見る限り、概念モデルと論理モデルが大きく乖離（かいり）することはなく、Entity Frameworkのマッピング機能をフル活用するというよりは、POCOによる迅速な開発が行えることに主眼が置かれているようである。 　しかし（個人的な感想だが）記事でサンプルとして示された、コード・ファーストによる開発スタイルには、Ruby on Railsを初めて見たときに近い衝撃を受けた。（積極的に活用するかは別として）データベースの自動生成機能まで備えているのには仰天である。 　この「コード・ファースト」はまだCTP（Community Technology Preview）4の段階だが、データベースに基づくアプリケーション開発の生産性を高めてくれる大きな可能性も感じ取れる、正式なリリースが楽しみな開発スタイルである。

まとめ

　Visual Studio 2010の拡張機能であるPOCO Entity Generatorを使うことにより、POCOによるエンティティ・クラスを短い手順で生成することができた。記事冒頭にも記したとおり、POCOによるエンティティ・クラスのサポートは、N層アーキテクチャでのEntity Frameworkの活用へとつながっていく。

　次回は「自己追跡エンティティ」と呼ばれる、.NET Framework 4でサポートされた新しい機能を活用し、N層アーキテクチャにおいて、データ変更を適切に管理する手法について検討したい。

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

　

「ADO.NET Entity Framework入門」

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