私は、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に接続文字列を与える必要がある理由について混乱している場合(メモリ内のデータベースで機能し、コンテキストに直接接続を提供するため)、 ドキュメントはそれを少し明確にします-それはエンティティ接続文字列は、スキーマを構築できるようにモデルを見つけるための努力に必要な情報を提供するため、エンティティフレームワークのデータベースファーストまたはモデルファーストのバリアントを使用している場合にのみ必要です!!したがって、接続文字列のserver / database / user id / password部分にダミー名を安全に入力できます。
これにより、カスタムのデフォルトのDbConnectionFactoryアプローチがコードファーストでのみ機能することも明確になります。これは、最初に取得したエラーの数時間を説明します。モデルファーストまたはデータベースファーストでは、エンティティ接続をエンティティクラスに挿入する必要があります、 ここで説明されているように 。
役に立つヒント-生成されたエンティティモデルクラスは部分クラスであるため、同じアセンブリに別のコードファイルを作成し、同じ名前空間を与えて部分クラスにすることもできます。また、代わりにそのコードファイルへのEntityConnectionを使用すると、エンティティモデルを変更/再作成するときに、カスタムコンストラクターを含むコードはt4テンプレートによって削除されません。