Entity Framework Code First in Teamwork

翻訳者から：Entity Framework 6の移行メカニズムと、チームで作業するときに移行の競合を解決する方法を理解するための優れた記事。 元の記事： チーム環境でのCode First Migrations 。



この記事は、Entity Frameworkとその基本的な操作に精通していることを前提としています。 それ以外の場合は、先に進む前に最初にCode First Migrationsを読む必要があります。

一杯のコーヒーを注ぐ、あなたは記事全体を読む必要があります

チームワークでは、問題は主に2人の開発者がローカルデータベースに作成した移行のマージに関連しています。 これらの問題を解決する手順は非常に簡単ですが、移行の仕組みを明確に理解する必要があります。 記事全体を注意深く読んでください。

一般的な原則

複数の開発者が作成した移行のマージを管理する方法を詳しく調べる前に、いくつかの一般的な原則を示します。

各チームメンバーには、ローカル開発データベースが必要です。

移行エンジンは、 __ MigrationsHistoryテーブルを使用して、データベースに適用された移行のリストを保存します。 チームに移行を生成する開発者が複数いる場合、同じデータベース（したがって、同じ__MigrationsHistoryテーブル）で作業しようとすると、移行メカニズムが困難になる可能性があります。

もちろん、移行を作成しないチームメンバーがいる場合、開発用の中央データベースを使用しても問題はありません。

自動移行を避ける

一番下の行は、自動移行は最初はチームワークで見栄えが良いが、実際には機能しないということです。 理由を知りたい場合は、記事を読み続けてください。そうでない場合は、次の章に進んでください。



自動移行により、コード移行（コードベースの移行）でファイルを作成することなく、現在のモデルに従ってデータベーススキーマを更新できます。



自動移行は、これまで使用したことがあり、コードベースの移行を作成したことがない場合にのみ、チーム作業でうまく機能します。 問題は、自動移行が制限されており、プロパティ/列の名前の変更、あるテーブルから別のテーブルへのデータの転送など、多くの操作に対応できないことです。 このようなシナリオを処理するには、最終的にコードベースの移行を作成（および生成されたコードを編集）し、自動移行を使用して処理される変更を混合します。 これにより、2人の開発者間で変更をマージすることはほとんど不可能になります。



翻訳者から：オリジナルの記事に2つのスクリーンキャストが投稿されています。読むことをお勧めします

移行のメカニズムの原則

チームで移行を正常に使用するための鍵は、移行メカニズムがモデル情報を追跡および使用して変更を検出する方法を基本的に理解することです。

最初の移行

最初の移行をプロジェクトに追加するとき、パッケージマネージャーコンソールでAdd-Migration Firstなどを実行します。 このコマンドが実行する手順を以下に示します。







コードに基づいて、現在のモデル（1）が計算されます。 次に、異なるモデルを使用して、必要なデータベースオブジェクトが計算されます（2）-これは最初の移行であるため、モデルの違いは比較のために空のモデルを使用します。 必要な変更はコードジェネレーターに転送され、必要な移行コード（3）が作成され、Visual Studioソリューション（4）に追加されます。



メインファイルに格納されている移行コードに加えて、移行メカニズムは追加の分離コードファイルも作成します。 これらは、移行エンジンで使用されるメタデータファイルであり、変更しないでください。 これらのファイルの1つはリソースファイル（.resx）で、移行が作成されたときのモデルのスナップショットが含まれています。 次のセクションでは、その使用方法を確認します。



この時点で、 Update-Databaseを実行してデータベースに変更を適用し、アプリケーションの残りの実装を開始できます。

後続の移行

モデルにいくつかの変更を加えます。この例では、 UrlプロパティをBlogクラスに追加します。 次に、 Add-Migration AddUrlコマンドを実行して移行を作成し、適切な変更をデータベースに適用する必要があります。 このコマンドが実行する手順を以下に示します。







前回同様、現在のモデルはコードから計算されます（1）。 ただし、今回は既存の移行があり、以前のモデルは最後の移行から抽出されます（2）。 これらの2つのモデルを比較して、データベースで必要な変更を見つけ（3）、その後、プロセスは以前のように終了します。



同じプロセスは、プロジェクトに追加される次のすべての移行に使用されます。

モデルショットで湯気を立てる理由

EFが比較のためにモデルスナップショットを使用する理由を疑問に思うかもしれません。データベースを単に見てはいけません。

EFがモデルの状態を保持する理由はいくつかあります。

• これにより、データベースをEFモデルとは異なるものにすることができます。 これらの変更は、データベースで直接行うことができます。または、移行のスキャフォールドコードを変更して変更することもできます。 これが実際のいくつかの例です：
  
  
  • 挿入列と更新列を1つ以上のテーブルに追加したいが、EFモデルに含めたくない場合。 移行エンジンがデータベースを調べた場合、移行コードを生成するたびにこれらの列を常に削除しようとします。 モデルスナップショットを使用すると、EFはモデル内の必要な変更のみを検出します。
    
    
  • 特定のデバッグ情報を更新するために使用されるストアドプロシージャの本体を変更する場合。 移行メカニズムがデータベース内のストアドプロシージャを調べた場合、彼は絶えずそれを定義にリセットしようとします。 モデルスナップショットを使用する場合、EFは、EFモデルのプロシージャを変更すると、ストアドプロシージャを変更するコードを生成します
    
    
  • データベース内のテーブルの追加、EFからDBビューへのマッピングなど、追加のインデックスを追加する場合にも同じ原則が適用されます。
    
    
  
  
  
• EFモデルには、データベースイメージだけではありません。 モデルがある場合、移行メカニズムにより、モデルのプロパティとクラス、およびそれらが列とテーブルにどのようにマップされるかに関する情報を表示できます。 この情報により、自動コード生成により移行エンジンがよりスマートになります。 たとえば、列の名前を変更すると、移行マッピングは名前の変更を検出し、同じプロパティであることを確認します。 データベースだけを見ると不可能です
  
  

チームワークの問題の原因

前のセクションで説明したプロセスは、アプリケーションで作業している開発者があなただけである場合に最適です。 モデルを変更するのがあなただけである場合、彼はチームでもうまく機能します。 この場合、モデルに変更を加え、移行を生成し、それらをバージョン管理システムに送信できます。 他の開発者は、そのような変更を受け取り、 Update-Databaseを実行してスキーマを更新する場合があります。



EFモデルに変更を加えてバージョン管理システムに送信する開発者が数人いると、問題が発生し始めます。 EFに欠けているのは、ローカルの移行を、最後の同期後にバージョン管理システムに送られた他の開発者の移行と組み合わせる一流の方法です。

競合のマージの例

まず、このような競合をマージする特定の例を見てみましょう。 前に調べた例から続けます。 出発点として、前のセクションからの変更がこの開発者によって検証されたと仮定しましょう。 コードを変更する2人の開発者を追跡します。



一連の変更を通じて、EFモデルと移行を追跡します。 次の図に示すように、両方の開発者はバージョン管理システムのリポジトリを介して同期します。







開発者＃1と開発者＃2は、ローカルコードベースのEFモデルにいくつかの変更を加えます。 開発者＃1はRatingクラスをBlogクラスに追加し、 AddRating移行を作成して、変更をデータベースに適用します。 開発者＃2はReaderクラスをBlogクラスに追加し、 AddReaders移行を作成します。 両方の開発者は、 Update-Databaseを実行してローカルデータベースに変更を適用し、アプリケーションの開発を続けます。



注：移行はタイムスタンプで始まるため、この図は、開発者＃2からのAddReaders移行が、開発者＃1からのAddRating移行の後に来ることを示しています。 チームワークの観点からは、これらの変更がどのような順序で作成されるかは重要ではありません。次のセクションでそれらを結合するプロセスを検討します。







今日、開発者＃1は、バージョン管理システムへの変更を最初に投稿したので幸運でした。 誰もリポジトリに変更を送信していないため、マージを実行せずに変更を簡単に投稿できます。







次に、開発者＃2が変更を送信するときです。 彼はそれほどラッキーではありません。 なぜなら 最後の同期後に誰かが変更を投稿した場合、開発者はそれらを選択してマージする必要があります。 バージョン管理システムは、非常に単純なので、コードレベルで変更を自動的にマージできる可能性があります。 同期後のローカル開発者コードベース＃2のステータスを次の図に示します。







この時点で、開発者＃2はUpdate-Databaseを実行できます。これにより、新しいAddRating移行（開発者＃2データベースには適用されていない）を検出して適用できます。 これで、 評価列がブログテーブルに追加され、データベースがモデルと同期されます。



たとえば、いくつかの問題があります。

1. Update-Database操作はAddRating移行を適用しますが、警告も表示します。
   
   保留中の変更があり、自動移行が無効になっているため、現在のモデルに一致するようにデータベースを更新できません...
   
   問題は、モデルのスナップショットが最後の移行（AddReader）に格納され、 ブログクラスのRatingプロパティがスキップされることです（移行の作成時にモデルの一部ではなかったため）。
   
   
   
   Code Firstは、以前の移行のモデルが現在のモデルと一致しないことを検出し、警告を表示します。
   
   
2. アプリケーションを実行すると、InvalidOperationExceptionが発生します。「データベースが作成されてから、「BloggingContext」コンテキストをサポートするモデルが変更されました。 Code First Migrationsを使用してデータベースを更新することを検討してください... "
   
   
   
   繰り返しますが、問題は、モデルのスナップショットが現在のモデルと一致しない最後の移行に保存されることです
   
   
3. 最後に、 Add-Migrationの起動により空の移行が生成されると予想されます（データベースに適用する必要のある変更がないため）。 ただし、移行では、最後の移行（ Ratingプロパティを持たない）の1つで現在のモデルを比較するため、 Rating列を追加する別のAddColumn呼び出しが生成されます。
   
   
   
   もちろん、 評価列が既に存在するため、 Update-Databaseではこの移行は失敗します。
   
   

競合解決のマージ

幸いなことに、移行の仕組みを理解していれば、手動で移行をマージすることはそれほど難しくありません。 この記事の冒頭を見逃した場合は...申し訳ありませんが、最初に戻って記事の最初の部分を読む必要があります！



2つのオプションがありますが、最も簡単なのは、モデルの正しいスナップショットを持つ空の移行を作成することです。 2番目のオプションは、モデルの正しいスナップショットを取得するために、最後の移行でスナップショットを更新することです。 これはもう少し複雑で、このオプションはすべての場合に使用できるわけではありません。 その利点は、追加の移行を追加する必要がないことです。

オプション1：空の「マージ」移行を追加する

このオプションでは、最後の移行にモデルの正しいスナップショットが保存されるように、空の移行のみを生成します。



この機能は、最後の移行の作成者に関係なく使用できます。 この例では、最後の移行を生成した開発者＃2を監視しました。 ただし、開発者＃1が最後の移行を生成した場合、これらの同じ手順を使用できます。 この手順は、複数の移行がある場合にも適用されます。



次のアルゴリズムは、バージョン管理システムと同期する必要がある変更が表示された瞬間から使用できます。

1. ローカルコードベースのすべてのモデル変更が移行で保存されていることを確認してください。 この手順により、クリーンな移行を作成するときに重要な変更を見逃すことがなくなります。
   
   
2. コードをバージョン管理システムと同期する
3. Update-Databaseを実行して、他の開発者が行った新しい移行を適用します。
   
   注： Update-Databaseの実行中に警告が表示されない場合、他の開発者からの新しい移行はなく、追加のマージを実行する必要はありません。
   
   
4. Add-Migration <pick_a_name> -ignorechangesを実行します（例： add-migration merge -ignorechanges ）。 このコマンドは、すべてのメタデータ（現在のモデルのスナップショットを含む）で移行を作成しますが、現在のモデルを最後の移行のスナップショットと比較するときに検出した変更を無視します（つまり、空のUpメソッドとDownメソッドを取得します）。
   
   
5. 開発を続けるか、バージョン管理システムに変更を送信します（もちろん単体テストを開始した後）。

これは、このアプローチを適用した後の開発者モデル＃2の状態です。

オプション2：最新の移行モデルのスナップショットを更新する

このオプションはオプション1と非常に似ていますが、不要な空の移行を削除します。



このアプローチは、最後の移行がローカルにのみ存在し、まだバージョン管理システムに送信されていない場合（つまり、最後の移行がマージを実行するユーザーによって作成された場合）に可能です。 他の開発者が使用する、またはさらに悪いことに戦闘データベースに適用される移行メタデータを編集すると、予期しない副作用が発生する可能性があります。 このプロセスでは、ローカルデータベースへの最後の移行をロールバックし、更新されたメタデータを再適用します。



最後の移行がローカルである限り、移行の数や順序に制限はありません。

同じ手順が、複数の異なる開発者からの複数の移行に適用されます。



バージョン管理システムと同期する必要がある変更が表示される場合、次のアルゴリズムを使用できます。

1. ローカルコードベースのすべてのモデル変更が移行で保存されていることを確認してください。
   
   この手順により、クリーンな移行を作成するときに重要な変更を見逃すことがなくなります。
   
   
2. コードをバージョン管理システムと同期します。
3. Update-Databaseを実行して、他の開発者が行った新しい移行を適用します。
   
   
   
   注： Update-Databaseの実行中に警告が表示されない場合、他の開発者からの新しい移行はなく、追加のマージを実行する必要はありません。
   
   
4. Update-Database -TargetMigration <second_last_migration>を実行します （この例では、これはUpdate-Database -TargetMigration AddRatingになります ）。
   
   
   
   このアクションにより、データベースは移行の最後の1つの状態にロールバックされます。実際、
   
   データベースへの最後の移行が適用されなかった場合。
   
   
   
   注：メタデータはデータベースの__MigrationsHistoryテーブルにも保存されるため、このステップは移行メタデータを安全に編集するために必要です。 そのため、最後の移行がローカルのみである場合にのみ、この機能を使用する必要があります。 最後の移行を他のデータベースに適用する必要がある場合は、それをロールバックし、最後の移行を再適用してメタデータを更新する必要もあります。
   
   
5. Add-Migration <full_name_include_timestamp_of_last_migration>を実行します（この例では、 Add-Migration 201311062215252_AddReaders migration add -onsのようになります）。
   
   
   
   注：新しい移行を作成するのではなく、既存の移行を変更することを移行エンジンが理解できるように、ラベルを指定する必要があります。 これにより、現在のモデルに合うように最新の移行のメタデータが更新されます。 コマンドが完了すると、次の警告が表示されますが、これはまさにあなたが望むものです。 「移行用のデザイナーコード '201311062215252_AddReaders'のみが再スキャフォールドされました。 移行全体の足場を再設定するには、-Forceパラメーターを使用します。
6. Update-Databaseを実行して、更新されたメタデータで最新の移行を再適用します。
   
   
7. 開発を続けるか、バージョン管理システムに変更を送信します（もちろん単体テストを開始した後）。

これは、このアプローチを適用した後の開発者＃2のローカルコードベースの状態です。

合計

チームでCode First移行を使用する場合、いくつかの問題があります。 ただし、移行の仕組みに関する一般的な理解と、マージの競合を解決するためのいくつかの簡単なアプローチにより、これらの問題を簡単に克服できます。



基本的な問題は、最後の移行で保存される誤ったメタデータです。 これにより、Code Firstは現在のモデルとデータベーススキーマが一致しないことを誤って判断し、次の移行のために誤ったコードを生成します。 この状況は、正しいモデルで空の移行を生成するか、最新の移行でメタデータを更新することで修正できます。