Entity Frameworkを使用してDbContext接続を作成し、web.configファイルに「DbContext」接続文字列があります。
次に、ログインしようとしましたが、私のWebサイトでは、ユーザーテーブルを作成するために別の「defaultConnection」文字列が必要でした。
この場合、2つの接続が必要ですか？それとも、どういうわけか2つを組み合わせて、1つの接続を確立する必要がありますか？
パフォーマンスの面でどちらが優れていますか？インターネットアプリケーションテンプレートを使用してプロジェクトの構築を開始しました。
メンバーシップとロールの既定では、ASP.netインフラストラクチャは、デフォルトのメンバーシップと役割のプロバイダーを使用して、そのメンバーシップと役割のデータを別のデータベースに格納します。アプリケーションを実行し、ログインページからユーザーを登録すると、作成された「App_Data」フォルダーの場所にデータベースが表示されます。データベースが異なるため、接続文字列が異なります。エンティティフレームワークを使用しているため、ここから2つの方法があります。
1）接続文字列を変更し、同じデフォルトのasp.netメンバーシップおよびロールプロバイダーを使用して、エンティティフレームワーク構成が使用しているデータベースにデータを格納します。これは、デフォルトのメンバーシッププロバイダーとロールプロバイダーが、EF構成が指すデータベースを使用することを意味します。
2）EFを使用して、メンバーシップとロールのデータを管理します。したがって、ユーザーとグループはDBcontext、他のエンティティとして管理されるエンティティになります。
私は最近、2番目のアプローチを実装しました。ASP.netメンバーシップは、独自のプロバイダーを実装し、それらをweb.configファイルに登録するためのフック（拡張性）を提供します。次に、User and Roleエンティティを作成し、それらをに含めますDBContext。もちろん、プロバイダーを登録する前に、クラスから派生しMembershipProviderてRoleProvider抽象クラスを作成することにより、プロバイダーを実装する必要があります。これらのクラスは`System.Web.Security'名前空間にあります。
詳細については、このプロジェクトをフォローできますhttp://codefirstmembership.codeplex.com/
別のデータベースへの接続はパフォーマンスに影響を与えないと思います。Webモデルの場合と同様に、着信要求に同じデータベースを使用する場合でも、データベースに個別に接続する必要があり、着信要求は同時に発生する可能性があります。実際、データベースを分離しておくと、別のサーバーへのデータベースのロードが必要になります。しかし、今ではバックアップと保守を行うサーバーが2台あります。他のアプリケーションでも共有されるなどの理由でメンバーシップデータを分離する必要がない限り、これは維持できません。
ある時点で、さまざまなテーブルからユーザーテーブルへの外部キーが必要になる可能性があるため、この2つを組み合わせることをお勧めします。
web.configに「DefaultConnection」という1つの接続があります。
次に、を初期化するときに、次DbContextのようにDbContext(string)オーバーロードを使用してDefaultConnectionを使用します。var context = new YourDbContext("DefaultConnection");
そうすれば、データとユーザー/ロールテーブルがいつまでも幸せに共存できます。