EF 6 MSSQLおよびPostgresSQLとどのように友達になったか

むかしむかし、MSSQL DBMSでEF 6にプロジェクトがありました。 また、PostgreSQLと連携する機能を追加する必要がありました。 このトピックについては多数の記事があり、フォーラムでは同様の問題の議論を見つけることができるため、ここでは問題を想定していませんでした。 ただし、実際には、すべてがそれほど単純であるとは限りませんでした。この記事では、この経験、新しいプロバイダーの統合中に発生した問題、選択したソリューションについて説明します。

入門

箱入りの製品があり、すでに確立された構造を持っています。 最初は、1つのDBMS-MSSQLで動作するように構成されていました。 プロジェクトには、EF 6実装（コードファーストアプローチ）のデータアクセスレイヤーがあります。 EF 6 Migrationsを通じて移行を処理します。 移行は手動で作成されます。 データベースの初期インストールは、引数として渡された接続文字列のコンテキストの初期化とともに、コンソールアプリケーションから行われます。

static void Main(string[] args) { if (args.Length == 0) { throw new Exception("No arguments in command line"); } var connectionString = args[0]; Console.WriteLine($"Initializing dbcontext via {connectionString}"); try { using (var context = MyDbContext(connectionString)) { Console.WriteLine("Database created"); } } catch (Exception e) { Console.WriteLine(e.Message); throw; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同時に、EFインフラストラクチャとドメインドメインは、ライブラリとしてコンソールアプリケーションに接続されている別のプロジェクトで説明されています。 インフラストラクチャプロジェクトのコンテキストコンストラクターは次のようになります。

 public class MyDbContext : IdentityDbContext<User, Role, Key, UserLogin, UserRole, UserClaim>, IUnitOfWork { public MyDbContext(string connectionString) : base(connectionString) { Database.SetInitializer(new DbInitializer()); Database.Initialize(true); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の打ち上げ

最初に行ったのは、Nugetを介して2つのパッケージをプロジェクトに接続することでした：NpgsqlとEntityFramework6.Npgsql。



また、Postgresのコンソールアプリケーション設定のApp.configにも登録されています。



entityFrameworkセクションは、デフォルトのpostgresファクトリを接続ファクトリとして指定しました。

 <entityFramework> <!--<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />--> <defaultConnectionFactory type="Npgsql.NpgsqlConnectionFactory, EntityFramework6.Npgsql" /> <providers> <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" /> <provider invariantName="Npgsql" type="Npgsql.NpgsqlServices, EntityFramework6.Npgsql" /> </providers> </entityFramework>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DbProviderFactoriesセクションで、新しいプロバイダーのファクトリーが登録されました。

 <system.data> <DbProviderFactories> <add name="Npgsql Data Provider" invariant="Npgsql" support="FF" description=".Net Framework Data Provider for Postgresql" type="Npgsql.NpgsqlFactory, Npgsql" /> </DbProviderFactories> </system.data>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてすぐに、彼らは接続文字列にPostgresサーバーアドレスとサーバー管理者資格情報を示して、データベース額を初期化しようとしました。 結果は次の行です。

「サーバー= localhost; データベース= TestPostgresDB; 統合セキュリティ= false; ユーザーID = postgres; パスワード= pa $$ w0rd”

予想どおり、手動のEF移行モードのおかげで、初期化は機能せず、現在のモデルのデータベースイメージと一致しないエラーが発生しました。 新しいプロバイダーを使用したプライマリ移行の作成を回避し、Postgresでデータベースの初期化をテストするために、インフラストラクチャ構成をわずかに調整しました。



最初に、「自動移行」を有効にしました。これは、ある開発者がチーム内のドメインモデルとEFインフラストラクチャに変更を加える場合に便利なオプションです。

 public sealed class Configuration : DbMigrationsConfiguration<MyDbContext> { public Configuration() { AutomaticMigrationsEnabled = true; ContextKey = "Project.Infrastructure.MyDbContext"; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、継承クラスCreateDatabaseIfNotExistsの再定義されたメソッドInitializeDatabaseで新しいプロバイダーを指定し、移行を開始します。

 public class DbInitializer : CreateDatabaseIfNotExists<MyDbContext> { public override void InitializeDatabase(MyDbContext context) { DbMigrator dbMigrator = new DbMigrator(new Configuration { //TargetDatabase = new DbConnectionInfo(context.Database.Connection.ConnectionString, "System.Data.SqlClient") TargetDatabase = new DbConnectionInfo(context.Database.Connection.ConnectionString, "Npgsql") }); // There some code for run migrations } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、同じ接続文字列を引数として使用して、コンソールアプリケーションを再度起動しました。 今回、コンテキストの初期化はエラーなしで行われ、ドメインモデルは新しいPostgresデータベースに安全に適合しました。 「__MigrationHistory」ラベルが新しいデータベースに表示され、最初に自動作成された移行の単一のレコードがありました。



要約すると、問題なく新しいプロバイダーを既存のプロジェクトに接続することができましたが、同時に移行メカニズムの設定を変更しました。

手動移行モードをオンにする

前述のように、自動移行モードが有効になっている場合、ドメインおよびデータアクセス領域での並行開発をチームから奪います。 私たちにとって、このオプションは受け入れられませんでした。 そのため、プロジェクトで手動移行モードを設定する必要がありました。



最初に、AutomaticMigrationsEnabledフィールドをfalseに戻しました。 次に、新しい移行の作成に対処する必要がありました。 異なるDBMSの移行は、少なくとも異なるプロジェクトフォルダーに保存する必要があることを理解しました。 そのため、PostgresMigrationsと呼ばれるインフラストラクチャプロジェクトにPostgres移行用の新しいフォルダー（MsSql移行があるフォルダー、わかりやすくするためにMsSqlMigrationsと名前を変更しました）を作成し、MsSql移行構成ファイルをコピーすることにしました。 同時に、既存のMsSql移行のすべてをPostgresSqlにコピーしませんでした。 まず、これらにはすべてMsSqlプロバイダーの構成のスナップショットが含まれているため、新しいDBMSでそれらを使用することはできません。 第二に、変更の履歴は新しいDBMSにとって重要ではなく、ドメインモデルの状態の最新のスナップショットで対処できます。



私たちは、すべてがPostgresへの最初の移行を形成する準備ができていると考えました。 自動移行モードをオンにしてコンテキストの初期化中に作成されたデータベースが削除されました。 また、最初の移行では、ドメインモデルの現在の状態に基づいて物理データベースを作成する必要があるという事実に基づいて、接続文字列パラメーターのみを指定して、パッケージマネージャーコンソールでUpdate-Databaseコマンドを喜んで採点しました。 その結果、DBMSへの接続に関連するエラーが発生しました。



データベースの更新チームがどのように機能するかをさらに検討して、次のことを行いました。

• 次のコードを移行構成設定に追加しました。
  
  
  
  MsSqlの場合：
  
  
  
  

   public Configuration() { AutomaticMigrationsEnabled = false; ContextKey = "Project.Infrastructure.MyDbContext"; MigrationsDirectory = @"MsSqlMigrations"; }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  Postgresの場合：
  
  
  
  

   public Configuration() { AutomaticMigrationsEnabled = false; ContextKey = "Project.Infrastructure.MyDbContext"; MigrationsDirectory = @"PostgresMigrations"; }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

• プロバイダーの名前を渡すUpdate-Databaseコマンドの必要なパラメーターを示しました
• efインフラストラクチャの説明を含むプロジェクト、および新しいプロバイダーの移行構成を含むフォルダーを示すパラメーターを追加しました

その結果、次のコマンドが取得されました。

データベースの更新-ProjectName "Project.Infrastructure" -ConfigurationTypeName Project.Infrastructure.PostgresMigrations.Configuration -ConnectionString "Server = localhost; データベース= TestPostgresDB; 統合セキュリティ= false; ユーザーID = postgres; パスワード= pa $$ w0rd "-ConnectionProviderName" Npgsql "

このコマンドを実行した後、同様のパラメーターでAdd-Migrationコマンドを実行し、最初の移行にInitialCreateという名前を付けました。

Add-Migration -Name "InitialCreate" -ProjectName "CrossTech.DSS.Infrastructure" -ConfigurationTypeName CrossTech.DSS.Infrastructure.PostgresMigrations.Configuration -ConnectionString "Server = localhost; データベース= TestPostgresDB; 統合セキュリティ= false; ユーザーID = postgres; パスワード= pa $$ w0rd "-ConnectionProviderName" Npgsql "

PostgresMigrationsフォルダーに新しいファイルが出現しました：2017010120705068_InitialCreate.cs



次に、Update-Databaseコマンドの実行後に作成されたデータベースを削除し、上記の接続文字列を引数として使用してコンソールアプリケーションを起動しました。 そのため、手動で作成した移行に基づいてデータベースを既に取得しています。



要約すると、最小限の労力で、Postgresプロバイダーの最初の移行を追加し、コンソールアプリケーションを介してコンテキストを初期化して、最初の手動移行からの変更が入った新しいデータベースを取得することができました。

プロバイダーを切り替える

まだ1つの未解決の質問がありました。実行時に特定のDBMSにアクセスできるようにコンテキストの初期化を構成する方法ですか。



タスクは、コンテキストの初期化段階で、目的のプロバイダーの1つまたは別のターゲットデータベースを選択できることでした。 このスイッチの設定を繰り返し試行した結果、次のようなソリューションを思い付きました。



app.configのプロジェクトのコンソールアプリケーション（およびapp.configを使用しない場合はmachine.config）で、プロバイダーと接続名を使用して新しい接続文字列を追加し、コンテキストコンストラクターで接続文字列の代わりに接続名を「ドロップスルー」します。 同時に、DbConfigurationインスタンスのシングルトンを介して接続文字列自体をコンテキストに接続します。 DbConfigurationから継承されたクラスのインスタンスをパラメーターとして渡します。



結果のレガシーDbConfigurationクラス：

 public class DbConfig : DbConfiguration { public DbConfig(string connectionName, string connectionString, string provideName) { ConfigurationManager.ConnectionStrings.Add(new ConnectionStringSettings(connectionName, connectionString, provideName)); switch (connectionName) { case "PostgresDbConnection": this.SetDefaultConnectionFactory(new NpgsqlConnectionFactory()); this.SetProviderServices(provideName, NpgsqlServices.Instance); this.SetProviderFactory(provideName, NpgsqlFactory.Instance); break; case "MsSqlDbConnection": this.SetDefaultConnectionFactory(new SqlConnectionFactory()); this.SetProviderServices(provideName, SqlProviderServices.Instance); this.SetProviderFactory(provideName, SqlClientFactory.Instance); this.SetDefaultConnectionFactory(new SqlConnectionFactory()); break; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、コンテキストの初期化自体は次のようになります。

 var connectionName = args[0]; var connectionString = args[1]; var provideName = args[2]; DbConfiguration.SetConfiguration(new DbConfig(connectionName, connectionString, provideName)); using (var context = MyDbContext(connectionName)) { Console.WriteLine("Database created"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、慎重にフォローした人は、おそらくコードにもう1つ変更を加える必要があることに気付いたでしょう。 これは、前述のInitializeDatabaseメソッドで発生するデータベース初期化中のターゲットデータベースの定義です。



特定のプロバイダーの移行構成を決定する単純なスイッチを追加しました。

 public class DbInitializer : CreateDatabaseIfNotExists<MyDbContext> { private string _connectionName; public DbInitializer(string connectionName) { _connectionName = connectionName; } public override void InitializeDatabase(MyDbContext context) { DbMigrationsConfiguration<MyDbContext> config; switch (_connectionName) { case "PostgresDbConnection": config = new PostgresMigrations.Configuration(); break; case "MsSqlDbConnection": config = new MsSqlMigrations.Configuration(); break; default: config = null; break; } if (config == null) return; config.TargetDatabase = new DbConnectionInfo(_connectionName); DbMigrator dbMigrator = new DbMigrator(config); // There some code for run migrations } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、コンテキストコンストラクター自体は次のようになり始めました。

 public MyDbContext(string connectionNameParam) : base(connectionString) { Database.SetInitializer(new DbInitializer(connectionName = connectionNameParam)); Database.Initialize(true); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、コンソールアプリケーションを起動し、MsSqlアプリケーションパラメーターをDBMSプロバイダーとして指定しました。 アプリケーションの引数を次のように設定します。

"MsSqlDbConnection" "サーバー= localhost \ SQLEXPRESS; データベース= TestMsSqlDB; ユーザーID = sa; パスワード= pa $$ w0rd "" System.Data.SqlClient "

MsSqlデータベースはエラーなしで作成されました。



次に、アプリケーションの引数を指定しました。

"PostgresDbConnection" "サーバー= localhost; データベース= TestPostgresDB; 統合セキュリティ= false; ユーザーID = postgres; パスワード= pa $$ w0rd "" Npgsql "

Postgresデータベースもエラーなしで作成されました。



したがって、もう1つの小計-EFが特定のプロバイダーのデータベースコンテキストを初期化するには、実行時に以下が必要です。

• このプロバイダーへの移行メカニズムを「示す」
• コンテキストの初期化の前にDBMS接続文字列を構成する

チームで2つのDBMSの移行に取り組みます

見てきたように、最も興味深い部分は、ドメインに新しい変更が出現した後に始まります。 特定のプロバイダーを考慮して、2つのDBMSの移行を生成する必要があります。



そのため、MSSQL Serverの場合、シーケンシャルコマンドを実行する必要があります（最初の移行を作成するときに、上記のコマンドであるPostgresの場合）。

• 最後のスナップショットに従ってデータベースを更新する
  
  

  データベースの更新-ProjectName "Project.Infrastructure" -ConfigurationTypeName Project.Infrastructure.MsSqlMigrations.Configuration -ConnectionString "Server = localhost; データベース= TestMsSqlDB; 統合セキュリティ= false; ユーザーID = sa; パスワード= pa $$ w0rd "-ConnectionProviderName" System.Data.SqlClient "

• 新しい移行を追加する
  
  

  Add-Migration -Name "SomeMigrationName" -ProjectName "Project.Infrastructure" -ConfigurationTypeName Project.Infrastructure.MsSqlMigrations.Configuration -ConnectionString "Server = localhost; データベース= TestMsSqlDB; 統合セキュリティ= false; ユーザーID = sa; パスワード= pa $$ w0rd "-ConnectionProviderName" System.Data.SqlClient "

開発者がドメインに並行して変更を加えると、バージョン管理システムでこれらの変更をマージするときに複数の競合が発生します（簡単にするためにgitと呼びます）。 これは、EFへの移行が次々と連続して行われるためです。 また、ある開発者が移行を作成した場合、別の開発者は移行を連続して追加することはできません。 後続の各移行には、前の移行に関する情報が保存されます。 したがって、移行のいわゆるモデルのスナップショットを最後に作成されたスナップショットに更新する必要があります。



同時に、チーム内でのEF移行の競合の解決は、特定の開発者の変更の重要性を優先することに帰着します。 また、変更の優先度が高い場合は、それらを最初にgitに入力する必要があり、合意された階層に従って他の開発者は次のことを行う必要があります。

1. 作成されたローカル移行を削除する
2. リポジトリから自分自身に変更をプルします。優先度の高い他の同僚が既に移行を注ぎ込んでいます。
3. ローカル移行を作成し、結果の変更をgitにアップロードします

EFの移行メカニズムに精通している限り、説明されているチーム開発アプローチは現時点で唯一のものであると判断できます。 このソリューションは理想的ではありませんが、生命に対する権利があります。 そして、EF Migrationsメカニズムに代わるものを見つけるという問題が私たちにとって緊急になっています。

結論として

EF Migrationsと組み合わせてEF6を使用していくつかのDBMSを操作することは現実ですが、このバージョンでは、Microsoftのスタッフはバージョン管理システムを使用したチームの並行作業の可能性を考慮しませんでした。



市場には、DbUp、RoundhousE、ThinkingHome.Migrator、FluentMigratorなど、多くの代替EF移行ソリューション（有料および無料）があります。 レビューから判断すると、彼らはEF Migrationsよりも開発者に似ています。



幸いなことに、プロジェクトで何らかのアップグレードを行う機会があります。 そして近い将来、EF Coreに切り替えます。 EF Core Migrationsメカニズムの長所と短所を比較検討し、サードパーティのソリューション（Fluent Migrator）を使用する方が便利だという結論に達しました。



あなたが私たちの経験に興味を持っていたことを願っています。 Wellcome、コメントを受け入れて質問に答える準備ができました！