CODEWITHSUNDEEP
ef-code-firstasp.net-membershipasp.net-mvc-4
rINArISA
rINArISA

Reputation: 49

MVC4 membership connection using Entity Framework

I created a DbContext connection using Entity Framework and have "DbContext" connection string in my web.config file.

Then, I tried to log in, and my website required me to have another "defaultConnection" string for creating user tables.

In this case, do I need to have two connections? Or should I have one connection by somehow combining the two?

Which is better performance-wise? I started building my project using Internet Application template.

Upvotes: 1

Views: 1338

Answers (2)

Joshua
Joshua

Reputation: 4139

I would suggest combining the two, since at some point you will probably want foreign key's from various tables to the Users table.

I would have one connection in the web.config, "DefaultConnection".

Then when you initialize your DbContext, use the DbContext(string) overload to use the DefaultConnection, like so: var context = new YourDbContext("DefaultConnection");

That way your data and Users/Roles tables live together, happily ever after.

Upvotes: 0

Abhijit-K
Abhijit-K

Reputation: 3669

By default for membership and roles, the ASP.net infrastructure uses the default membership and role providers that stores that membership and roles data in different database. Run your application and if you register for a user from login page you can see the database at location "App_Data" folder created. The database is different hence the connection string is different. You are using entity framework so there are 2 ways to go from here.

1) Change the connection string and use the same default asp.net membership and role providers to store data in the database that your entity framework configuration is using. By this I mean the default membership and role providers use the database that you EF configuration points to.

2) Use EF to manage the membership and roles data. So the users and groups would be entities manages by the DBcontext as other entities.

I have recently implemented the second approach. The ASP.net membership provides hooks (extensibility) to implement your own providers and register them in the web.config file. Then create the User and Role entity and include them in DBContext. Of-course before registering the providers you need to implement them first by deriving from MembershipProvider and RoleProvider abstract classes. These classes are in `System.Web.Security' namespace.

You can follow this project for more details http://codefirstmembership.codeplex.com/

I believe the connections to separate database will not have any impact on the performance. As in the web model even if you use same database for incoming requests we have to make connections to database separately and the incoming requests can come concurrent. In fact keeping the database separate will take to database load to another server. But now you have 2 servers to back up and maintain. This will not be maintainable unless you want your membership data to be separate for some reasons like it is shared by other applications also.

Upvotes: 1

Related Questions