Effortフレームワークでユニットテストで既存のデータベースを使用できません
質問
私は、Azure SQLでホストされているデータベースを使用して、Entity Framework 6のEffortフレームワークでテストを作成しようとしています。
次のコードを実行すると、例外がスローされます。
[ClassInitialize]
public static void ClassInitialize(TestContext context)
{
EffortProviderConfiguration.RegisterProvider();
}
[TestMethod]
public void TestMethod1()
{
const string connectionString = "Data Source=***;Initial Catalog=my_catalog;User ID=user;Password=password;provider=System.Data.SqlClient";
IDataLoader loader = new EntityDataLoader(connectionString);
using (var ctx = new UsersDbContext(Effort.DbConnectionFactory.CreatePersistent("cool", loader)))
{
var usersCount = ctx.Users.Count();
}
}
Count()実行でスローされる例外：
Effort.Exceptions.EffortException： 'テーブル'テーブルの内容を初期化しようとしたときに未処理の例外---> System.ArgumentException：キーワードがサポートされていません： 'データソース'。
EffortProviderConfiguration.RegisterProvider()をEffortProviderConfiguration.RegisterProvider()設定に置き換えると、同じ例外がスローされます。
UsersDbContext作成にまったく同じ接続文字列を使用すると、成功し、データにアクセスできます。さらに、接続文字列を使用せずにEffort永続モードまたは一時モードを使用してコンテキストを作成することも有効です。
実際のDBから既存のデータとの接続を初期化するにはどうすればよいですか？
人気のある回答
私のように、Effortに接続文字列を与えなければならない理由（なぜなら、メモリ内のデータベースで動作し、コンテキストに直接接続を提供する必要がある）が混乱しているとすれば、 ドキュメントによって少し明確になります。 Entity Frameworkのデータベースファーストまたはモデルファーストバリアントを使用している場合にのみ必要ですエンティティ接続文字列は、スキーマを構築できるようにモデルを配置するために必要な情報を提供します。したがって、接続文字列のサーバー/データベース/ユーザーID /パスワードの部分をダミーの名前で安全に埋めることができます。
これはまた、カスタムのデフォルトのDbConnectionFactoryアプローチが、コード・ファーストでのみ機能することを明らかにしています。これは、最初の数時間のエラーを説明しています。モデルの最初またはデータベースでは、Entity Connectionをエンティティ・クラスに注入する必要がありますここで説明します 。
便利なヒント - 生成されたエンティティモデルクラスが部分クラスであるため、同じアセンブリ内に別のコードファイルを作成し、同じ名前空間にして部分クラスにすることができます。エンティティモデルを変更/再作成すると、カスタムコンストラクタのコードはt4テンプレートによって削除されません。