トレーニングコース。 ASP.NET MVCのEntity Frameworkとの同時実行

これは、Entity FrameworkとASP.NET MVC 3を使用した開発に関する一連の記事の最後の部分です。最初の章は、次のリンクにあります。

• ASP.NET MVCアプリケーションのEntity Frameworkデータモデルの作成
• ASP.NET MVCアプリケーションでEntity Frameworkを使用して基本的なCRUD機能を実装する
• ASP.NET MVCアプリケーションでEntity Frameworkを使用して並べ替え、フィルター処理、およびページ分割を行う
• ASP.NET MVCアプリケーション用の複雑なデータモデルの作成
• ASP.NET MVCアプリケーションの複雑なデータモデルの作成、パート2
• ASP.NET MVCアプリケーションでEntity Frameworkからデータをロードする
• ASP.NET MVCアプリケーションでEntity Frameworkを使用して関連データを更新する

前のレッスンでは、関連データを操作しました。 このレッスンでは、同時アクセスの問題に対処します。 Departmentエンティティで機能するページを作成し、Departmentエンティティを編集および削除するためのページも同時実行エラーを処理します。 結果を図に示します。





同時アクセスの競合

1人のユーザーが1つのエンティティに関するデータを表示してさらに編集し、同時に別のユーザーが同じデータを更新してから最初のユーザーによる変更がデータベースに保存されると、同時アクセスの競合が発生します。 EFがそのような競合を検出するように構成されていない場合、データベースを最後に更新したものが以前に行った変更を上書きします。 多くのアプリケーションでは、リスクは重要ではありません。複数のユーザー、複数の更新、または変更の書き換えがそれほど重要ではない場合、同時実行指向プログラミングのコストはこの利点よりも高くなります。 この場合、そのような状況を処理するようにアプリケーションを構成する必要はありません。

悲観的並行性（ロック）

アプリケーションが同時アクセス競合の結果としての偶発的なデータ損失を防ぐ必要がある場合、問題を解決する方法の1つはテーブルをロックすることです。 これは、悲観的同時実行性と呼ばれます 。 たとえば、データベースからレコードをダウンロードする前に、読み取り専用または更新アクセスのロックを要求します。 この方法で変更へのアクセスをブロックすると、他のユーザーはデータのコピーのみを受け取るため、このレコードを読み取り専用からブロックしたり、アクセスを変更したりすることはできません。 読み取り専用アクセスへの書き込みアクセスをブロックすると、他のユーザーも読み取り専用アクセスにロックできますが、変更はできません。

ロック管理には欠点があります。 プログラミングは複雑すぎる可能性があり、ロックには深刻なデータベースリソースが必要であり、アプリケーションのユーザー数が増えるとダウンロードのオーバーヘッドが増加します。 この点で、すべてのDBMSが悲観的同時実行性をサポートしているわけではありません。 Entity Frameworkは、悲観的な同時実行性の組み込みメカニズムを提供しません。このレッスンでは、このアプローチは考慮しません。

楽観的並行性

悲観的並行性の代替は、 楽観的並行性です。 楽観的同時実行により、同時アクセスの競合が発生する可能性がありますが、そのような状況に適切に対応することができます。 たとえば、JohnはDepartments Editページを開き、英語ブランチの予算値を350,000.00ドルから100,000.00ドルに変更します。



ジョンが[保存]ボタンをクリックする前に、ジェーンは同じページを開き、 [開始 日]の値を1/1/1999に変更します。



ジョンは最初に[ 保存 ]ボタンを押して変更を確認し、その瞬間にジェーンがボタンを押します。 以下は、このような状況をどのように処理するかに依存します。 次の方法を使用して処理できます。

• どのプロパティが編集されたかの記録を保持し、データベース内の対応する列のみを更新できます。 この例では、さまざまなプロパティがさまざまなユーザーによって編集されているため、データは失われません。 次回、英語ブランチのデータを表示するとき、ユーザーにはJohnとJaneの両方による変更が表示されます。

この方法は、データの損失を伴う状況の数を減らすことができますが、エンティティの単一のプロパティを編集する場合には役立ちません。 ただし、古いプロパティ値と新しいプロパティ値を追跡するには大量のデータを管理する必要があるため、この方法の使用はWebアプリケーションではめったに見られません。 大量のデータを管理すると、アプリケーションのパフォーマンスに影響する可能性があります。

• Janeの変更でJohnの変更を上書きできます。 その後、次のユーザーには1/1/1999が表示され、古い値は$ 350,000.00です。 このスクリプトは、 Client WinsまたはLast in Winsと呼ばれます。 これは、アプリケーションの動作を変更しない場合、自動的に発生します。
• ジェーンの変更のためにデータベースを更新することはできません。エラーをスローし、データの現在の状態を表示し、ページを更新して、データを再入力します。 このスクリプトはStore Winsと呼ばれます。 このチュートリアルでは、このシナリオを使用します。 変更が失われないこと、および同時アクセスの競合がユーザーにタイムリーに通知されることが保証されます。

同時アクセス競合検出

EFによってスローされるOptimisticConcurrencyExceptionを処理することにより、このタイプの競合を解決できます。 この例外をいつスローするかを知るために、EFは競合がいつ発生するかを判断できなければなりません。 したがって、データベースとデータモデルを適切に構成する必要があります。 このセットアップには、次のオプションを使用できます。

• データベースのテーブルに、「追跡」列を含めます。この列は、レコードがいつ変更されたかを判断するために使用できます。 その後、この列を更新クエリまたは削除クエリのWhere句に含めることができます。

通常、この列のデータ型はタイムスタンプですが、実際には日付や時刻は保存されません。 代わりに、値はデータが更新されるたびに1ずつ増加する数字に等しくなります（SQL Serverの最近のバージョンでは、同じデータ型がrowversion型である場合があります）。 更新クエリまたは削除クエリでは、Whereステートメントに「トラッキング」列の元の値が含まれます。 更新プロセス中にユーザーがレコードを編集した場合、この列の値は元の値とは異なるため、更新クエリと削除クエリはこのレコードを見つけることができません。 EFは、UpdateまたはDelete要求で何も更新されていないことを検出すると、これを同時アクセス競合と見なします。

• UpdateおよびDeleteクエリのWhereステートメントに各列のソースデータを含めるようにEFを構成します。

1つのオプションとして、レコードが最初にロードされてから何も変更されていない場合、Whereステートメントは更新のためにレコードを返さず、EFは競合として認識します。 このオプションは、フォローアップ列オプションと同じくらい効果的です。 ただし、多数の列を持つテーブルがある場合、このアプローチを使用すると、多数のWhereステートメントが発生し、データと状態の大きな配列を管理する必要が生じる可能性があります。 ほとんどの場合、このアプローチの使用は推奨されません。

このレッスンでは、「追跡」列をDepartmentエンティティに追加し、コントローラーとビューを作成して、すべてを一緒にテストします。

「追跡」列なしで並列処理を実装する場合、すべての列が更新クエリのWhereステートメントに含まれることをEFに指定して、すべての非プライマリキーをConcurrencyCheck属性でマークする必要があります。

部署の エンティティに追跡列を追加する

モデル \ 部門 。 csは「トラッキング」列を追加します。

[Timestamp] public Byte[] Timestamp { get; set; } 

Timestamp属性は、この列がUpdateおよびDeleteクエリのWhereステートメントに含まれることを決定します。

コントローラー 作成

部門コントローラーとビューを作成します。



Controllers \ DepartmentController.csで次を使用して追加します。

System.Data.Entity.Infrastructureを使用します。

ファイル全体（4つのエントリ）でLastNameをFullNameに変更して、学部管理者のドロップダウンリストに姓ではなくフルネームが表示されるようにします。

HttpPost Editメソッドコードを次のように置き換えます。

 [HttpPost] public ActionResult Edit(Department department) { try { if (ModelState.IsValid) { db.Entry(department).State = EntityState.Modified; db.SaveChanges(); return RedirectToAction("Index"); } } catch (DbUpdateConcurrencyException ex) { var entry = ex.Entries.Single(); var databaseValues = (Department)entry.GetDatabaseValues().ToObject(); var clientValues = (Department)entry.Entity; if (databaseValues.Name != clientValues.Name) ModelState.AddModelError("Name", "Current value: " + databaseValues.Name); if (databaseValues.Budget != clientValues.Budget) ModelState.AddModelError("Budget", "Current value: " + String.Format("{0:c}", databaseValues.Budget)); if (databaseValues.StartDate != clientValues.StartDate) ModelState.AddModelError("StartDate", "Current value: " + String.Format("{0:d}", databaseValues.StartDate)); if (databaseValues.InstructorID != clientValues.InstructorID) ModelState.AddModelError("InstructorID", "Current value: " + db.Instructors.Find(databaseValues.InstructorID).FullName); ModelState.AddModelError(string.Empty, "The record you attempted to edit " + "was modified by another user after you got the original value. The " + "edit operation was canceled and the current values in the database " + "have been displayed. If you still want to edit this record, click " + "the Save button again. Otherwise click the Back to List hyperlink."); department.Timestamp = databaseValues.Timestamp; } catch (DataException) { //Log the error (add a variable name after Exception) ModelState.AddModelError(string.Empty, "Unable to save changes. Try again, and if the problem persists contact your system administrator."); } ViewBag.InstructorID = new SelectList(db.Instructors, "InstructorID", "FullName", department.InstructorID); return View(department); } 

ビューには、非表示フィールドに「トラッキング」列の元の値が表示されます。 部門インスタンスを作成するとき、このオブジェクトはTimestampプロパティに値を持ちません。 次に、EF更新リクエストを作成した後、リクエストには、元のタイムスタンプ値を持つレコードの検索条件を含むWhereステートメントが含まれます。

Update要求で更新が更新されない場合、EFはDbUpdateConcurrencyExceptionをスローし、catchブロックのコードは例外に関連付けられたDepartmentエンティティを返します。 このエンティティには、元のプロパティ値と新しいプロパティ値があります。

 var entry = ex.Entries.Single(); var databaseValues = (Department)entry.GetDatabaseValues().ToObject(); var clientValues = (Department)entry.Entity; 

さらに、コードは、ユーザーが編集ページで入力した値とは異なるデータベース内の値を持つ各列にエラーメッセージを追加します。

 if (databaseValues.Name != currentValues.Name) ModelState.AddModelError("Name", "Current value: " + databaseValues.Name); // ... 

エラーの場合、詳細なメッセージが表示されます。

 ModelState.AddModelError(string.Empty, "The record you attempted to edit " + "was modified by another user after you got the original value. The" + "edit operation was canceled and the current values in the database " + "have been displayed. If you still want to edit this record, click " + "the Save button again. Otherwise click the Back to List hyperlink."); 

最後に、コードはDepartmentオブジェクトのTimestampプロパティの値をデータベースから取得した新しい値に設定します。 この新しい値は、[編集]ページが更新されると非表示フィールドに保存され、次回[保存]をクリックすると、ページの再読み込み後に発生した同時実行エラーのみがキャッチされます。

ビュー \ 部門 \ 編集で 。 cshtmlは、DepartmentIDプロパティの非表示フィールドの直後に、非表示フィールドを追加してタイムスタンプ値を保存します。

Html .HiddenFor（model => model.Timestamp）

ビュー \ 部門 \ インデックスで 。 cshtmlはコードを置き換えて、エントリリンクを左に移動し、ページヘッダーと列を変更します。

 @model IEnumerable<ContosoUniversity.Models.Department> @{ ViewBag.Title = "Departments"; } <h2>Departments</h2> <p> @Html.ActionLink("Create New", "Create") </p> <table> <tr> <th></th> <th>Name</th> <th>Budget</th> <th>Start Date</th> <th>Administrator</th> </tr> @foreach (var item in Model) { <tr> <td> @Html.ActionLink("Edit", "Edit", new { id=item.DepartmentID }) | @Html.ActionLink("Details", "Details", new { id=item.DepartmentID }) | @Html.ActionLink("Delete", "Delete", new { id=item.DepartmentID }) </td> <td> @Html.DisplayFor(modelItem => item.Name) </td> <td> @Html.DisplayFor(modelItem => item.Budget) </td> <td> @Html.DisplayFor(modelItem => item.StartDate) </td> <td> @Html.DisplayFor(modelItem => item.Administrator.FullName) </td> </tr> } </table> 

楽観的同時実行のテスト

プロジェクトを実行し、 Departmentsをクリックします。



[ 編集]リンクをクリックし、別のブラウザウィンドウで別の編集ページを開きます。 Windowsは同一の情報を表示するはずです。



最初のブラウザウィンドウでフィールドを変更し、[ 保存 ]をクリックします 。



変更されたデータを含むインデックスページが表示されます。



2番目のブラウザウィンドウで同じフィールドを別の値に変更します。



[ 保存]をクリックして、エラーメッセージを表示します。



[ 保存]をもう一度クリックします 。 2番目のブラウザーウィンドウに入力した値はデータベースに保存され、変更が[インデックス]ページに表示されたことがわかります。



削除ページの追加

削除ページの場合、同時実行の問題は同様に処理されます。 HttpGet Deleteメソッドによって確認ウィンドウが表示されると、ビューの非表示フィールドに元のタイムスタンプ値が含まれます。 この値は、ユーザーが削除を確認したときに呼び出されるHttpPost Deleteメソッドで使用できます。 EFが削除要求を作成する場合、この要求には元のタイムスタンプ値を含むWhereステートメントが含まれます。 リクエストが何も返さない場合は、同時実行例外がスローされ、エラーパラメータをtrueに設定してHttpGet Deleteメソッドが呼び出され、エラーメッセージを含む確認ページが再ロードされます。

DepartmentControllerで 。 csは、HttpGet Deleteメソッドのコードを次のように置き換えます。

 public ActionResult Delete(int id, bool? concurrencyError) { if (concurrencyError.GetValueOrDefault()) { ViewBag.ConcurrencyErrorMessage = "The record you attempted to delete " + "was modified by another user after you got the original values. " + "The delete operation was canceled and the current values in the " + "database have been displayed. If you still want to delete this " + "record, click the Delete button again. Otherwise " + "click the Back to List hyperlink."; } Department department = db.Departments.Find(id); return View(department); } 

このメソッドは、同時実行エラーの後にページをリロードするかどうかを決定するオプションのパラメーターを受け入れます。 trueに設定されている場合、エラーメッセージはViewBagプロパティのビューに送信されます。

HttpPost Delete（DeleteConfirmed）メソッドコードを次のコードに置き換えます。

 [HttpPost, ActionName("Delete")] public ActionResult DeleteConfirmed(Department department) { try { db.Entry(department).State = EntityState.Deleted; db.SaveChanges(); return RedirectToAction("Index"); } catch (DbUpdateConcurrencyException) { return RedirectToAction("Delete", new System.Web.Routing.RouteValueDictionary { { "concurrencyError", true } }); } catch (DataException) { //Log the error (add a variable name after Exception) ModelState.AddModelError(string.Empty, "Unable to save changes. Try again, and if the problem persists contact your system administrator."); return View(department); } } 

最初は、メソッドはレコードIDの値のみを受け入れました。

パブリックActionResult DeleteConfirmed（int id）

このパラメーターをDepartmentエンティティに変更すると、Timestampプロパティにアクセスできます。

パブリックActionResult DeleteConfirmed（部門）

同時実行エラーがスローされた場合、コードはエラーパラメーターが設定された確認ページをリロードします。

ビュー \ 部門 \ 削除で 。 cshtmlは、エラーメッセージのフォーマットとフィールドを提供するコードでコードを置き換えます。

 @model ContosoUniversity.Models.Department @{ ViewBag.Title = "Delete"; } <h2>Delete</h2> <p class="error">@ViewBag.ConcurrencyErrorMessage</p> <h3>Are you sure you want to delete this?</h3> <fieldset> <legend>Department</legend> <div class="display-label"> @Html.LabelFor(model => model.Name) </div> <div class="display-field"> @Html.DisplayFor(model => model.Name) </div> <div class="display-label"> @Html.LabelFor(model => model.Budget) </div> <div class="display-field"> @Html.DisplayFor(model => model.Budget) </div> <div class="display-label"> @Html.LabelFor(model => model.StartDate) </div> <div class="display-field"> @Html.DisplayFor(model => model.StartDate) </div> <div class="display-label"> @Html.LabelFor(model => model.InstructorID) </div> <div class="display-field"> @Html.DisplayFor(model => model.Administrator.FullName) </div> </fieldset> @using (Html.BeginForm()) { @Html.HiddenFor(model => model.DepartmentID) @Html.HiddenFor(model => model.Timestamp) <p> <input type="submit" value="Delete" /> | @Html.ActionLink("Back to List", "Index") </p> } 

このコードは、h2ヘッダーとh3ヘッダーの間にエラーメッセージを追加します。

<p class = "error"> @ ViewBag.ConcurrencyErrorMessage </ p>

AdministratorフィールドのLastNameをFullNameに置き換えます。

 <div class="display-label"> @Html.LabelFor(model => model.InstructorID) </div> <div class="display-field"> @Html.DisplayFor(model => model.Administrator.FullName) </div> 

最後に、DepartmentIDとTimestampの非表示フィールドが追加されます。

 @Html.HiddenFor(model => model.DepartmentID) @Html.HiddenFor(model => model.Timestamp) 

別のブラウザウィンドウで部門インデックスページを開きます。

最初のウィンドウで、[ 編集 ]をクリックしていずれかの値を変更しますが、[ 保存 ]をクリックしないでください。



2番目のウィンドウで、同じ学部の[削除]をクリックします。 確認ウィンドウが表示されます。



最初のブラウザウィンドウで[ 保存]をクリックします 。 変更が確認されます。



次に、2番目のブラウザーウィンドウで[削除]をクリックして、同時実行エラーメッセージを表示します。 データが更新されます。



もう一度[削除]をクリックすると、教員のエントリが削除されたことを確認するインデックスページが開きます。

同時アクセス競合の導入を完了しました。 詳細については、 楽観的同時実行パターンとプロパティ値の操作を参照してください。 次のレッスンでは、エンティティInstructorとStudentの継承を実装する方法を示します。

謝辞

Alexander Belotserkovskyの翻訳にご協力いただきありがとうございます。