💀 🐄 📠 あなたが知らないかもしれないEntity Framework 6の拡張 💴 🔨 💸

多くのプログラマーは、メモを作成し、困難を説明し、自分の義務のために対処しなければならない美しくてそれほど難しくない決定をします。それはあなた自身の技術的なブログ、働くwiki、または通常のノートブックでさえありえます-本質は一つです。徐々に、小さなEvernoteから、Habrの記事全体が成長する可能性があると指摘されています。しかし、時間が経ち、仕事の変更が開発スタックの変更を約束し、技術はまだ止まりません（ところで、バージョン1.1のように、EF Coreは数か月間存在していました）。一方、Entity Framework 6は、特にその安定性、低いしきい値、幅広い人気により、.netスタック上の企業アプリケーションのデータにアクセスするための主力製品であり続けています。したがって、この記事がまだ誰かに役立つことを願っています。

内容：

EDMXなしのデータベースファースト
切断されたグラフを操作する
SQLの変更。テーブルの方向を追加する
DbContextライフタイムキャッシング
SQL Serverからのエラーを再試行する
DbContextを置き換え、実際のデータベースから分離
クイック挿入

EDMXなしのデータベースファースト

「コードファーストとデータベースファースト」の議論の次のラウンドを開始したくありません。 Database Firstを好むなら、あなたの人生をもっと楽にする方法を教えたほうがいいでしょう。このアプローチを使用する多くの開発者は、かさばるEDMXファイルで作業することの不便さに注目しています。このファイルは、チーム開発を地獄に変え、その内部構造の絶え間ない「混合」のために並行変更のマージを非常に複雑にします。数百のエンティティ（通常のレガシーモノリスなど）を含むモデルでは、他の欠点の中でも、標準のEDMXデザイナーで作業する場合、アクションの速度が大幅に低下する場合があります。

ソリューションは明らかなようです-POCOを生成してメタデータを保存する代替手段を支持して、EDMXを放棄する必要があります。タスクは難しくなく、EFには「すぐに使用可能」なものがあります。これは、Visual Studioで利用可能な「データベースからコードを最初に生成する」アイテムです（VS2015）。ただし、実際には、このツールを使用してデータベースの変更を結果のモデルに反映することは非常に不便です。さらに、EFで長い間働いてきた人は、同様の問題を解決するEntity Framework Power Tools拡張機能を覚えているかもしれませんが、残念ながら、プロジェクトはもう開発されておらず（VS2015をハックせずにインストールすることはできません）、このツールの一部の開発者はEFチームで直接作業しています

すべてが悪いように思えます。ここで、 EntityFramework Reverse POCO Generatorを見つけました。これは、多数の設定とオープンソースを持つ既存のデータベースに基づいてPOCOを生成するためのT4テンプレートです。すべての主要なEDMX機能がサポートされており、ユニットテスト用のFakeDbContext / FakeDbSetの生成、属性（例：DataContract / DataMember）などのモデルのカバーなど、多くの追加機能があります。T4のおかげで、コード生成を完全に制御できます。要約：安定して動作し、チームは気に入っています。既存のプロジェクトを簡単に移行できます。

切断されたグラフを操作する

通常、新しいコンテキストまたは以前に取得した異なるコンテキストの単一オブジェクトをDbContextにアタッチすることは難しくありません。問題は、グラフの場合に始まります。リンクのあるエンティティ-EF "out of the box"は、エンティティのナビゲーションプロパティのコンテンツの変更を追跡せず、コンテキストに再結合します。コンテキストの存続期間中、エンティティオブジェクトごとに変更を追跡するには、対応するエントリ（エンティティの状態（追加、変更、削除など）を含むサービス情報を持つオブジェクト）が存在する必要があります。グラフに参加するためのエントリを入力します-少なくとも2つの方法が可能です。

エンティティ自体に状態を保存し、変更を独自に追跡します。したがって、切断されたグラフには、参加に必要なすべての情報が含まれます。
事前に何もせずに、新しいコンテキストにグラフを追加するときに、データベースから元のグラフを取り出し、2つのグラフの比較に基づいてエントリ状態を配置します。

ソリューション＃1の例は、たとえば、有名なEFスペシャリストであるジュリーラーマンの最新のPluralsightコースにあります。独立した汎用実装には、多数のジェスチャが必要です。すべてのエンティティは、IStateObjectインターフェイスを実装する必要があります。

public interface IStateObject { ObjectState State { get; set; } }

何らかの方法で、グラフ内の各エンティティをコンテキストに手動で添付した後、状態値の関連性を確認する必要があります。

 context.Foos.Attach(foo);

すべてのエントリを調べて、状態を編集します。

 IStateObject entity = entry.Entity; entry.State = ConvertState(entity.State);

この場合、データベースへの追加の呼び出しは必要ありませんが、ソリューションは膨大で壊れやすく、多対多の関係では動作しない可能性があります。モデルも散らばっていました（ところで、インターフェースの実装要件は、記事の前のセクションのT4テンプレートを変更することで解決できます）。

解決策2を検討してください。簡単に説明します。

 context.UpdateGraph(root, map => map.OwnedCollection(r => r.Childs));

これを呼び出す-ルートエンティティをコンテキストに追加し、Children子オブジェクトのコレクションでナビゲーションプロパティを更新しますが、データベースへのSELECTのみのコストがかかります。 GraphDiffライブラリのおかげで可能になったのは、作者がすべての汚い仕事をし、主要なバグをキャッチしたからです。

SQLの変更。テーブルの方向を追加する

一見単純なSELECT ... FROM Table WITH（UPDLOCK）ステートメントの生成は、EFではサポートされていません。ただし、たとえば正規表現を使用するなど、適切な方法で生成されたSQLを変更できるインターセプターがあります。コンテキストの有効期間内に生成された各SELECTにUPDLOCKを追加しましょう（当然、粒度は必ずしもコンテキストではなく、すべて実装に依存します）。

 using (var ctx = new MyDbContext().With(SqlLockMode.UpdLock)) {}

これを行うには、コンテキスト内でWithメソッドを宣言し、インターセプターを登録します。

 public interface ILockContext { SqlLockMode LockMode { get; set; } MyDbContext With(SqlLockMode lockMode); } public class MyDbConfig : DbConfiguration { public MyDbConfig() { AddInterceptor(new LockInterceptor()); } } [DbConfigurationType(typeof(MyDbConfig))] public partial class MyDbContext : ILockContext { public SqlLockMode LockMode { get; set; } public MyDbContext With(SqlLockMode lockMode) { LockMode = lockMode; return this; } private static void MyDbContextStaticPartial() { } }

ロックインターセプター

 public class LockInterceptor : DbCommandInterceptor { public override void ScalarExecuting(DbCommand command, DbCommandInterceptionContext<object> interceptionContext) { AddLockStatement(command, interceptionContext); } public override void ReaderExecuting(DbCommand command, DbCommandInterceptionContext<DbDataReader> interceptionContext) { AddLockStatement(command, interceptionContext); } private void AddLockStatement<T>(DbCommand command, DbCommandInterceptionContext<T> interceptionContext) { var lockMode = GetLock(interceptionContext); switch (lockMode) { case SqlLockMode.UpdLock: command.CommandText = SqlModifier.AddUpdLock(command.CommandText); break; } } private SqlLockMode GetLock<T>(DbCommandInterceptionContext<T> interceptionContext) { if (interceptionContext == null) return SqlLockMode.None; ILockContext lockContext = interceptionContext.DbContexts.First() as ILockContext; if (lockContext == null) return SqlLockMode.None; return lockContext.LockMode; } }

正規表現は次のようになります。

 public static class SqlModifier { private static readonly Regex _regex = new Regex(@"(?<tableAlias>SELECT\s.*FROM\s.*AS \[Extent\d+])", RegexOptions.Multiline | RegexOptions.IgnoreCase); public static string AddUpdLock(string text) { return _regex.Replace(text, "${tableAlias} WITH (UPDLOCK)"); } }

正規表現のテスト

 public class SqlModifier_Tests { [TestCase("SELECT [Extent1].[Name] AS [Name] FROM [dbo].[Customer] AS [Extent1]")] [TestCase("SELECT * FROM [dbo].[Customer] AS [Extent999]")] public void AddUpdLock_ValidEfSelectStatement_AddLockAfterTableAlias(string text) { string expected = text + " WITH (UPDLOCK)"; string actual = SqlModifier.AddUpdLock(text); Assert.AreEqual(expected, actual); } [TestCase("SELECT [Extent1].[Extent1] AS [Extent1]")] [TestCase("SELECT * FROM Order")] [TestCase(" AS [Extent111]")] public void AddUpdLock_InvalidEfSelectStatement_NoChange(string text) { string actual = SqlModifier.AddUpdLock(text); Assert.AreEqual(text, actual); } }

DbContextライフタイムキャッシング

EFは次のようなものをキャッシュします。

クエリプラン。
メタデータ。
コンパイルされたクエリ。

データのキャッシングは人生のコンテキスト内でのみ行われ（Findメソッドを思い出してください）、この言語を本格的なキャッシュと呼ぶことはできません。プロセスメモリ内のすべてのコンテキストキャッシュ用に制御された統一されたキャッシュをどのように整理しますか？ EntityFramework.Plusまたはその「貧弱な」代替EntityFramework.Cacheを使用します。

 public void SelectWithCache() { using (var ctx = new MyDbContext()) { ctx.Customers.FromCache().ToList(); } } [Test] public void SelectWithCache_Test() { TimeSpan expiration = TimeSpan.FromSeconds(5); var options = new CacheItemPolicy() { SlidingExpiration = expiration }; QueryCacheManager.DefaultCacheItemPolicy = options; SelectWithCache(); //   SelectWithCache(); //  Thread.Sleep(expiration); SelectWithCache(); //   }

SelectWithCache（）の2回目の呼び出しがデータベースに影響しないことを確認するには、SQLプロファイラーを実行するだけで十分です。遅延ヒットもキャッシュされます。

さらに、EFと分散キャッシュの統合が可能です。たとえば、EntityFramework.Plusに接続されたSytem.Runtime.Caching.ObjectCacheに基づく自己記述型のキャッシュマネージャーを使用します。 NCache は、すぐに使用できるEFとの統合をサポートしています（詳細を共有できません-このキャッシュは試していません）。

SQL Serverからのエラーを再試行する

 public class SchoolConfiguration : DbConfiguration { public SchoolConfiguration() { SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy(maxRetryCount: 3, maxDelay: TimeSpan.FromSeconds(10))); } }

SqlAzureExecutionStrategy-この戦略はEF6に含まれています（既定では無効）。使用する場合、SQL Serverからの応答で特定のエラーコードを受信すると、サーバーにSQLステートメントが繰り返し送信されます。

SqlAzureExecutionStrategyのエラーコード

 // SQL Error Code: 40197 // The service has encountered an error processing your request. Please try again. case 40197: // SQL Error Code: 40501 // The service is currently busy. Retry the request after 10 seconds. case 40501: // SQL Error Code: 10053 // A transport-level error has occurred when receiving results from the server. // An established connection was aborted by the software in your host machine. case 10053: // SQL Error Code: 10054 // A transport-level error has occurred when sending the request to the server. // (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) case 10054: // SQL Error Code: 10060 // A network-related or instance-specific error occurred while establishing a connection to SQL Server. // The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server // is configured to allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed // because the connected party did not properly respond after a period of time, or established connection failed // because connected host has failed to respond.)"} case 10060: // SQL Error Code: 40613 // Database XXXX on server YYYY is not currently available. Please retry the connection later. If the problem persists, contact customer // support, and provide them the session tracing ID of ZZZZZ. case 40613: // SQL Error Code: 40143 // The service has encountered an error processing your request. Please try again. case 40143: // SQL Error Code: 233 // The client was unable to establish a connection because of an error during connection initialization process before login. // Possible causes include the following: the client tried to connect to an unsupported version of SQL Server; the server was too busy // to accept new connections; or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. // (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) case 233: // SQL Error Code: 64 // A connection was successfully established with the server, but then an error occurred during the login process. // (provider: TCP Provider, error: 0 - The specified network name is no longer available.) case 64: // DBNETLIB Error Code: 20 // The instance of SQL Server you attempted to connect to does not support encryption. case (int)ProcessNetLibErrorCode.EncryptionNotSupported: return true;

興味：

SqlAzureExecutionStrategyソースコードに基づいて、再試行につながるエラーコードをオーバーライドすることにより、独自の戦略を記述することができます。
SqlAzureExecutionStrategyを含む再試行戦略を使用すると、多くの制限が課せられますが、最も深刻なのはユーザートランザクションとの非互換性です。トランザクションを明示的に宣言するには、 System.Runtime.Remoting.Messaging.CallContextを呼び出して戦略を無効にします。
統合テストで戦略を説明することもできます（この問題について詳しく説明してくれたJulie Lermanに感謝します）。

DbContextを置き換え、実際のデータベースから分離

テストのために、呼び出しコードのDbContextを透過的に置き換え、偽のDbSetにテストデータを入力します。問題を解決する方法をいくつか紹介します。

方法＃1 （長い）：IMyDbContextおよびDbSetのスタブを手動で作成し、必要な動作を明示的に指定します。 Moqライブラリを使用すると、次のようになります。

モックデータベース

 public IMyDbContext Create() { var mockRepository = new MockRepository(MockBehavior.Default); var mockContext = mockRepository.Create<IMyDbContext>(); mockContext.Setup(x => x.SaveChanges()).Returns(int.MaxValue); var mockDbSet = MockDbSet<Customer>(customers); mockContext.Setup(m => m.Customers).Returns(mockDbSet.Object); return mockContext.Object; } private Mock<DbSet<T>> MockDbSet<T>(List<T> data = null) where T : class { if (data == null) data = new List<T>(); var queryable = data.AsQueryable(); var mock = new Mock<DbSet<T>>(); mock.As<IQueryable<T>>().Setup(m => m.Provider) .Returns(queryable.Provider); mock.As<IQueryable<T>>().Setup(m => m.Expression) .Returns(queryable.Expression); mock.As<IQueryable<T>>().Setup(m => m.ElementType) .Returns(queryable.ElementType); mock.As<IQueryable<T>>().Setup(m => m.GetEnumerator()) .Returns(queryable.GetEnumerator()); return mock; }

MSDNに関するこのトピックに関する基本的な記事があります：モックフレームワークを使用したEntity Framework Testing（EF6以降）。そして、このアプローチはかつて非常に印象的で、githubでデモプロジェクトを取得しました（EF6 DbFirst、SQL Server、Moq、Ninjectを使用）。ちなみに、エンタープライズコースで既に説明したEntity Frameworkのテストについては、章全体で説明します。

方法＃2 （短い）：既に説明したReverse POCO Generatorを使用します。これは、デフォルトでDbContextおよびすべてのDbSetのスタブを作成します（FakeDbSet内には通常のメモリ内コレクションがあります）。

クイック挿入

数千の新しいレコードをSQL Serverデータベースに同時に挿入するには、標準の行ごとのINSERTの代わりにBULK操作を使用するのが非常に効率的です。この問題については別の記事で詳しく説明しました。したがって、以下ではSqlBulkCopyに基づくすぐに使用できるソリューションのみを提供します。

→ EntityFramework.Utilities

→ エンティティフレームワーク拡張

それだけです。コメントでレシピやコツを共有してください=）

あなたが知らないかもしれないEntity Framework 6の拡張