この記事は機械翻訳されたものです。

データ ポイント

EF6 Alpha を使ってみる (機械翻訳)

Julie Lerman

 

Julie Lerman再生する何もない、光沢のある新しいおもちゃのようなそれが進化する夜間にダウンロードすることが可能エンティティ フレームワーク 6 (EF6) のビルドでは、(これは 10 月に来た。 最初のパッケージのアルファ リリースを待って 30, 2012年) 掘るし、再生を開始します。

「あれ? 自問している場合 夜間ビルドですか?」を逃すかもしれないこと EF5 リリース後エンティティ フレームワークは、オープン ソースのプロジェクトになったし、それ以降のバージョンをされているニュースで公然と (と共同) を開発した entityframework.codeplex.com。 「オープン ソース エンティティ Framework CodePlex サイトの周りにあなたの方法を作る」私は最近、ブログの記事を書いた (bit.ly/W9eqZS) は、CodePlex ページに向かう前にチェック アウトをお勧めします。

新しいバージョンより柔軟で拡張可能な EF を作るに向けた長い道のりを行きます。 私の意見では、EF をバージョン 6 に来て、3 つの最も重要な機能です。

  1. ストアド プロシージャと関数を最初のコードをサポートします。
  2. .NET 4.5 非同期/Await パターンのサポートは
  3. 現在、Microsoft .NET Framework 内部住んでいる Entity Framework Api のコア

この最後の点では、列挙型と、.NET Framework 4 を対象アプリケーションのための空間型のサポートを有効にするかだけでなく、EF はオープン ソースなのでそれも EF の今利益をすべてオープン ソースであることからを意味します。

これら 3 つの機能の広範な魅力をいない可能性がありますが、多くの他にも、その方法に重要な機能です。 たとえば、

  • EF4.1 のリリース前に引っ張ら得たカスタム コードの最初の規則が EF6 を実装する方法の様々 なです。
  • コードの最初の移行は複数のデータベース スキーマをサポートします。
  • それら (これは複雑になることができます) web.config または app.config ファイルで設定するのではなく、コードのエンティティ フレームワークの構成を定義できます。
  • コード ベースの構成は、依存関係競合回避モジュールと拡張のための新しいサポート可能です。
  • コードの最初の _Migrations を作成する方法をカスタマイズすることができます­履歴テーブル、さまざまなデータベース プロバイダーを受けやすいように。
  • EF 電力ツールされている強化し、Visual Studio EF デザイナーに追加します。 拡張の 1 つは、最初のコードを含む、モデルのワークフローを選択するためのよりよいパスを提供します。

EF6 アルファを取得

ハードコアの開発者は、ナイトリー ビルドをダウンロードするのに興味があります。 リリースのパッケージを使用する場合は、NuGet パッケージを取得することで経験にスムーズにインストールを持つことができます。 NuGet パッケージ マネージャーを使用して、「プレリリース EF6 パッケージを取得するを含める」を選択します。 パッケージ マネージャーからインストールする場合は、必ず追加します"-プレリリース"、インストール パッケージ コマンドの末尾に。

注意してください、12 月。 10、2012 年、(ファイルのバージョン 6.0.11025.0 と製品バージョン 6.0.0-alpha2-11210) 探索リリースしない、ストアド プロシージャまたは関数のサポート ツールの統合があります。 このような早いアルファであり、また、いくつかのこれらの機能の詳細は、新しいリリースで変更されます予測します。 全体的な概念のままになりますが、いくつかの構文やその他の詳細はコミュニティからのフィードバックに基づいて進化する可能性があります。 この列に作業の練習のおかげでは、自分自身のいくつかのフィードバックを提供することができた。

.NET 4.5 EF6 で非同期

使用してアプリケーションまたはリモート ・ データベースの切断特にときそれは返されるデータを待っているときにブロックを避けるために、.NET Framework での非同期処理を活用する多くの開発者がひるむが。 .NET Framework 2.0 では、バック グラウンドのワーカー プロセスに到着したが、まだ複雑なだった。 ADO.NET 2.0 の BeginExecuteQuery と EndExecuteQuery のような方法で助けにはなったが、エンティティ フレームワークはこれらのような何もしていなかった。 いずれかの .NET フレームワーク 4.5 の主要な追加は非同期に、非同期処理を大幅に簡素化が定義されている方法からの結果を待つことが新しい非同期パターンです。

EF6 でメソッドのスルーが追加されている、.NET 4.5 非同期パターンをサポートします。 新しいパターンのガイドラインに従って、すべての新しいメソッドがある SaveChangesAsync、実行する FindAsync と実行など、自分の名前を追加する非同期­SqlCommandAsync。 エンティティへの LINQ の System.Data.Entity.IQueryableExtensions と呼ばれる新しい名前空間が含まれている最初の ToListAsync を含む多くの LINQ メソッドの非同期バージョン­または­DefaultAsync、MaxAsync、SumAsync。 Dbcontext クラスでのマネージ エンティティからデータを明示的に読み込むには、LoadAsync 可能となりました。

以下は、私はこの機能では、非同期メソッドを使用しないで最初とし、それらを実施したちょっとした実験です。 私は非常に新しい非同期パターンを読んでお勧め。 「非同期と待機 (c# および Visual Basic)、非同期プログラミング」で利用可能な bit.ly/U8FzhPは、良い出発点します。

私の例には、カジノの評価が含まれていますカジノ クラスが含まれます。 与えられたカジノを見つけるし、(これはこの説明を取るに足らないと記載されていないそのため) 私 UpdateRating メソッドを使用してその評価をインクリメントして、変更をデータベースに保存するリポジトリ メソッドを作成しました。

public void IncrementCasinoRating(int id)
{
  using (var context = new CasinoSlotsModel())
  {
    var casino =  context.Casinos.Find(id);
    UpdateRating(casino);
    context.SaveChanges();
  }
}

スレッドがブロックを取得することができますこの方法で 2 つのポイントです。 最初の要求されたカジノのメモリ内キャッシュを検索し、それが見つからない場合、データベース クエリを実行するコンテキストが Find メソッドを呼び出すときです。 2 番目は、変更されたデータをデータベースに保存するコンテキストを確認するときです。

のみ関連する動作を示すために私の UI コードを構成しました。 UI には、リポジトリの IncrementCasinoRating を呼び出し、それが終わったら、通知、コンソールに書き込みますメソッドが含まれます。

private static void UI_RequestIncrement (SimpleRepository repo)
{
  repo.IncrementCasinoRating(1);
  Console.WriteLine("Synchronous Finish ");
}

UI_ のインクリメントを呼び出すことによって第一種トリガー テストの別のメソッドでは、­CasinoRating とは別の通知を実行します。

UI_RequestIncrement (repo);
Console.WriteLine(" After sync call");

私はこれを実行すると、コンソール出力に、以下が表示されます:

Synchronous Finish
After sync call

すべての各手順を完了する IncrementCasinoRating で待っている間停止だ —、カジノを見つけること、評価の更新、データベースへの保存します。

それは、新しい実行する FindAsync および SaveChangesAsync メソッドを使用するように、現在リポジトリ メソッドを変更します。 非同期パターンに従って、また、メソッドを非同期でにする必要があります。

  • async キーワードその署名に追加します。
  • 非同期メソッド名に追加します。
  • タスクを返します。 メソッドの結果を返す場合、タスク <resulttype> を返すだろう

メソッド内で、私は新しい非同期メソッドを呼び出す — 実行する FindAsync と SaveChangesAsync — 定める await キーワードを使用して。

public async Task IncrementCasinoRatingAsync(int id)
{
  using (var context = new CasinoSlotsModel())
  {
    var casino=await context.Casinos.FindAsync(id);
    // Rest is delayed until await has received results
    UpdateRating(casino);
    await context.SaveChangesAsync();
    // Method completion is delayed until await has received results
  }
}

最初の待機を当るとすぐ、メソッドは、非同期、マークされているため、メソッドは呼び出し側のプロセスに制御を返します。 しかし、私はその呼び出し元のメソッドを変更する必要があります。 動作ベースの非同期パターンをので建物だけを特別に私新しい非同期メソッドを呼び出すはないが滝パス、それもまだ別のプロセスによって呼び出されているので非同期自体をする必要があります。

private static async void UI_RequestIncrementAsync(
  SimpleRepository repo)
{
  await repo.IncrementCasinoRatingAsync(1);
  // Rest is delayed until await has received results
  Console.WriteLine(" Asynchronous Finish ");
}

私を使用して通知を待っていますリポジトリ メソッドを呼び出す。 この非同期メソッドは、呼び出し元することができます。 待ってすぐにヒット、制御を呼び出し元に返されます。 私はまた、スタートアップ コードを変更しました。

UI_RequestIncrementAsync(repo);
  Console.WriteLine(" After asynchronous call");

今私はこのコードを実行すると、UI_RequestIncrementAsync メソッド コントロールそれもリポジトリ メソッドを呼び出していると、呼び出し元を返します。 つまり、私はすぐに後非同期を呼び出す"."をプリント、スタートアップ コードの次の行を取得しますときリポジトリ メソッドが終了するデータベースへの保存、それはタスクをそれは、メッセージをコンソールに出力をコードの残りの部分を実行する UI_RequestIncrementAsync と呼ばれるメソッドを返します。

After asynchronous call
Asynchronous Finish

だから私の UI EF のため作業を完了するを待つことがなく終了することができた。 リポジトリ メソッドが結果を持っていた場合、彼らは準備ができていたとき彼らをタスクで泡立てているでしょう。

この小さな運動、新しい非同期メソッドのアクションを参照してください助けてください。 非同期処理に依存するクライアント側または切断のアプリケーションを書いているかどうか、EF6 今このようなシンプルで新しい非同期パターンをサポートすることは大きなメリットです。

カスタム規則

コードは、まずデータベース マッピング クラスからと共にモデルを作成するときは、既定の動作をドライブ内蔵の規則のセットがあります。 これらの規則は DataAnnotations または、Fluent API を使用して明示的な構成をオーバーライドできます。 コードの最初の初期のベータ版も独自の規則を定義できます-50 の最大長さのデータベース フィールドをマップするすべての文字列を設定します、コンベンションなど。 残念なことに、チームはこの機能を満足できる状態に最終的なリリースにそれをしなかったので最初のコードを保持することがなく得ることができるではなかった。 それ今 EF6 で復帰をしました。

独自の規則を定義するのには、いくつかがあります。

軽量の規則を使用する最も簡単な方法です。 規則は、流暢に、DbContext の OnModelCreating オーバー ロードを指定できます。 軽量規則をクラスに適用され、直接的な相関関係が MaxLength の長さなど、データベースのプロパティの構成に制限されています。 特別な構成のないクラスの例を示します、したがって、既定では、その 2 つの文字列フィールドを nvarchar (max) データ型を SQL Server データベースにマップします。

public class Hotel
  {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
  }

軽量のコンベンションでは、モデルの API がそれを処理して、文字列の最大長を 50 に設定任意のエンティティのプロパティを確認する必要があります指定が加わりました。

modelBuilder.Properties<string>()
  .Configure(p => p.HasColumnType("nvarchar"));

参照してくださいすることができます図 1 コード最初ことを確認、名と説明フィールドは 50 の最大長さを持っています。

A Custom Convention Made the Max Length of These nvarchars 50
図 1 カスタム規則にこれらの nvarchars 50 の最大長

DateTime プロパティを処理するため、条約のインターフェイスなどの既存のインターフェイスを実装することにより、規則を定義することができます-System.Data.Entity.ModelConfiguration.Configuration.Properties.Primitive 名前空間の DateTimePropertyConfiguration クラス。 図 2 私は強制 DateTime プロパティ既定 datetime ではなく SQL Server の日付型をマップする例を示しています。 このサンプルがマイクロソフトのガイダンスに従っていることに注意してください — 属性 (この場合は ColumnType) が既に構成されている場合私は私の設定は適用されません。

図 2 DateTime プロパティは SQL Server の日付型にマッピング

public  class DateTimeColumnTypeConvention :
  IConfigurationConvention<PropertyInfo, DateTimePropertyConfiguration>
  {
    public void Apply(
      PropertyInfo propertyInfo,
      Func<DateTimePropertyConfiguration> configuration)
    {
      // If ColumnType hasn't been configured ...
if (configuration().ColumnType == null)
      {
        configuration().ColumnType = "date";
      }
    }
  }

規則は、特定のくちばしでつつく順序、新しい ColumnType を適用する前に、列の型が既に構成されていないことを確かに持っている理由があります。

モデル ビルダーは、新条約を見つける方法を知っている必要があります。 ここでは、再び OnModelCreating でメソッドをオーバー ロードする方法は次のとおりです。

modelBuilder.Conventions.Add(new DateTimeColumnTypeConvention());

規則をカスタマイズする他の 2 つの方法があります。 1 つの方法でクラスを DataAnnotations として簡単に使用できるカスタムの属性を作成できます。 他の詳細です:ModelBuilder クラスから何を学ぶに依存する規則を構築することではなく、このメソッドでは、メタデータに直接影響することができます。 MSDN データ デベロッパー センターのドキュメントでは、「カスタム コード最初規則」のすべての 4 つスタイルのカスタム規則の例を見つけることができます (msdn.microsoft.com/data/jj819164)。 EF6 進化するにつれて、このドキュメントはより新しいバージョンへのリンクを得ることができるまたは最新バージョンとなるように変更します。

移行するための複数のスキーマのサポート

EF6 コードの最初の移行は複数のスキーマのデータベースを処理できます。 この機能について、まもなく、アルファがリリースされた後に書いた詳細なブログ記事を見て:「マルチ テナント移行 EF6 アルファに掘る」(bit.ly/Rrz1MD)。 ただし、機能の名前「からマルチ テナント移行」変更された心で「複数コンテキスト データベースごと」に維持を行う

コード ベースの構成

すでにアプリケーション構成ファイル (app.config と web.config) のエンティティ フレームワークのデータベースに関連する構成を指定できます構成をアプリケーションの起動時またはコンテキストのコンス トラクターを指定することから解放します。 今、EF6 のデータベース初期化戦略 (たとえば、DropCreateDatabaseIfModelChanges) と他のコードの最初の既定のデータベース プロバイダーなどの詳細を指定することができます、新しい DbConfiguration クラスから継承するクラスを作成することが可能です。 複数のコンテキストが 1 つの構成クラスから寄与することができますあなたのコンテキストと同じプロジェクトまたは別のプロジェクトでは、この DbConfiguration クラスを作成できます。 コード ベースの構成の概要を msdn.microsoft.com/data/jj680699 のさまざまなオプションの例を示します。

コア EF は今 EF6 とオープン ソースでも

コードの最初と DbContext Api は .NET のリリース サイクルから常に切断されている間は、EF のコア .NET Framework で埋め込まれています。 これはコア機能です — ObjectContext API、照会、変更の追跡、エンティティ­クライアント プロバイダーおよびそんなに多く。 これはなぜ列挙型をサポートし、空間データ 4.5 リリースされる .NET Framework を待機しなければならなかった-これらの変更はコア Api 内で深いなされなければならなかった。

EF6、コア Api のすべてのオープン ソース プロジェクトに引き出されている、NuGet パッケージ経由では展開されます。 示すように、EF5 と EF6 名前空間--並べてを参照してください面白いです図 3。 参照してくださいすることができます EF6 のとおり、多くの複数の名前空間。

EF6 Has Acquired the Namespaces of the EF Core APIs from the .NET Framework
図 3 EF6 EF コア Api、.NET framework の名前空間を取得しています

列挙型と .NET 4 の空間支援アプリ

前述のとおり、コア Api EF6 中の大きな利点の 1 つは .NET バージョン EF 固有の機能の依存性のいくつか削除することです-特に列挙型と .NET Framework 4.5 で EF を追加空間データのサポート。 EF を .NET Framework 4 を対象とする既存のアプリケーションは EF5 とこれを利用することができませんでした。 今は、この制限は EF6 には列挙型と空間のサポートが含まれています、したがってもはや .NET フレームワークに依存していますので、なくなっています。 これらの機能に関する既存のドキュメントは、それらを .NET Framework 4 を対象アプリケーションで使用することができます。

EF の進化を後押し

エンティティ フレームワークはオープン ソースのプロジェクトでは、開発者自身と他の人の設計や開発に関わることで助けることができます。 あなたの考え、コメント、フィードバックから、仕様を読んでかどうか、議論や最新の NuGet パッケージまたは夜間ビルドをつかむとそれらを叩いて遊んで問題に参加して共有できます。 コード、あなた自身の何かまたは誰もがまだ取り組んでいるサイトに記載されている問題のいずれかのいずれかをまた貢献することができます、EF でなければ生きていけない。

Julie Lerman は、バーモント ヒルズ在住の Microsoft MVP、.NET の指導者、およびコンサルタントです。世界中のユーザー グループやカンファレンスで、データ アクセスなどの Microsoft .NET トピックについてプレゼンテーションを行っています。彼女はブログで thedatafarm.com/blog 、「Entity Framework のプログラミング」の著者 (2010) (2011 年) コード最初の版、DbContext 版 (2012 年) だけでなく、オライリー メディアからすべてあり。Twitter ( twitter.com/julielerman、英語) で彼女をフォローしてください。

この記事のレビュー、次技術専門家のおかげで:グレン ・ Condron