ステップ 4：モデル層の作成
ではモデル・クラスを書いて、EF『コード・ファースト』を使用してそれらをNorthwindデータベースにマップします。以下はこれを有効化するために必要なコードすべてです。これ以外は不要です。
以下はこのコードが何を行うのか、またどのような動作をするのかについての詳細です。
POCOモデル・クラス
EF『コード・ファースト』により、データベース内でエンティティを表すために『プレーン・オールド・CLR・オブジェクト』（別名POCO）が使用できるようになります。つまり、ベースクラスからモデル・クラスを継承する必要も、その上でインターフェースや属性を実装する必要も無いということです。これにより、モデル・クラスをクリーンでPI（Persistence Ignorance）に保てます。
上記で2つのPOCOクラス、ProductとCategoryを定義しています。これらをNorthwindデータベース内のProductとCategoryテーブルを表すのに使用します。これら2つのクラス上のプロパティはテーブルのカラムにマップしています。ProductまたはCategoryクラスのそれぞれのインスタンスは、それぞれのデータベーステーブル内の行を表します。
Nullable型カラム
ProductクラスにあるいくつかのプロパティはNullable型に定義されています（これはDecimal?の意味で、Nullable型であることを示しています）。データベース内のNullable型カラムは、それらが値型であればモデル・クラス内でもNullable型プロパティとして表わされているはずです。
オプションとして、もしアクセスが必要無ければモデル・クラスからNullable型カラムの指定をすべて省略することも可能です。例えば、Northwind内のProductテーブルには、Nullable型のnvarcharであるQuantityPerUnitカラムとNullable型のsmallintであるUnitsOnOrderカラムがあります。上記で定義したProductクラスから、これらのプロパティは省略しています。これはデータベース内でNullable型になっており、なくても問題無くProductの取得、挿入、更新、削除ができます。
関連プロパティと遅延ローディング
EF『コード・ファースト』により、データベース内の主キー／外部キー関係の活用や、モデル・クラス上でプロパティを公開してそれらを使用しているモデル・クラス間でトラバースすることが簡単になります。上記ではProductクラス上でCategoryプロパティを、Categoryクラス上でProductプロパティを公開しています。これらのプロパティへアクセスすると、2つのテーブル間のPK／FK関係を使用して取得したモデルインスタンスを戻すことができます。
注意していただきたいのは、それらのプロパティ自体がまだPOCOプロパティであり、それらを定義するのにいずれかのEF指定コレクション型を使用する必要はありません。virtualとしてマークされている関連プロパティはデフォルトで遅延ロードされます。つまり、Productエンティティを取得すると、そのCategory情報はそのCategoryプロパティにアクセスするまで（またはProductオブジェクトを取得するためのLINQクエリを書くときにCategoryデータが取得されるべきであることを明示的に示さない限り）データベースから取得されません。
EFコンテキストクラス
ProductおよびCategory POCOクラスを作成した後、コンテキストクラスを作成するのにEF『コード・ファースト』を使用しました。それをデータベースのテーブルへ、またテーブルからPOCOモデル・クラスをマップするのに使用できます。
上記のNorthwindクラスは、ProductとCategoryクラスをデータベースへまたはデータベースからマップするために使用するコンテキストクラスです。それはEF『コード・ファースト』が提供するDbContextベースクラスから継承して、データベース内のテーブルに応答するための2つのプロパティを公開しています。このサンプルでは、データベースへまたはデータベースからクラスがどのようにマップされるべきかを定義するためのマッピング・ルールに基づいたデフォルトの設定に勝る規約を使用します。
もしモデル・クラスのオブジェクトモデルをデータベースのスキーマと異なるようにしたい場合、代わりにOnModelCreatingメソッドをオーバーライドして、独自のマッピング・ルールを指定できます。前回のEF『コード・ファースト』の投稿でこの方法をカバーしています。
ステップ 5：データベース接続文字列の構成
モデル層を定義するために必要なコードをすべて書きました。使用前の最後のステップはデータベースに接続するための接続文字列のセットアップです。
最初のEF『コード・ファースト』ブログ投稿で、EF『コード・ファースト』にはクールなオプションがあり、データベース・スキーマの自動作成／再作成ができることを話しました。これは特にグリーンフィールド開発シナリオに便利です。なぜならプロジェクトの早い段階で各モデルの変更後にデータベース・スキーマ更新に時間を費やすことなくモデル層に集中できるからです。
重要なのは、自動作成データベース・オプションがただのオプションだということで、絶対に必要なものではありません。既存のデータベースに接続文字列を設定すると、EF『コード・ファースト』は自動的に作成しません。自動再作成オプションもEFにこれを明示的に示さない限り有効化されませんので、データベースのドロップおよび再作成について心配する必要はありません。
このブログ投稿では、データベースの自動作成はしません。その代り、既にある既存のNorthwindデータベースをポイントします。これを行うには、web.configファイルにNorthwind接続文字列を次のように追加します。
<connectionStrings>
<add name="Northwind"
connectionString="data source=.\SQLEXPRESS;
Integrated Security=SSPI;
AttachDBFilename=|DataDirectory|orthwind.mdf;
User Instance=true"
providerName="System.Data.SqlClient" />
</connectionStrings>
EF『コード・ファースト』はコンテキストクラスがデフォルトでコンテキストクラスと同じ名前を持つ接続文字列を探す規約を使用します。これはコンテキストクラスがNorthwindと呼ばれているため、デフォルトではNorthwind接続文字列を探して使用します。上記のNorthwind接続文字列はローカルのSQL Expressデータベースを使用するように構成されています。代わりにリモートのSQL Serverをポイントすることもできます。
