Is Entity Framework compatible with ASP.NET Membership?

.net asp.net asp.net-membership entity-framework

Question

I'm constructing (really, re-making) an app that uses MS-Access databases to store existing user and other data. Users must be migrated as part of the transfer of the data to SQL Server. I am quite certain I understand what the data model in SQL Server will be, and I want to utilize EF to implement ORM. I want to use the Membership capabilities in ASP.NET even though I'm not new to EF or ASP.NET. I'm considering many options and am looking for some guidance. I haven't done any study on this concept yet; maybe the question has already been addressed somewhere else. So, let's move on to a group of connected queries.

  1. Can EF interact directly with ASP.NET Membership via an unidentified class or namespace?

  2. If I move users to the Membership system, should I build additional user data tables on top of the aspnet_* tables, similar to what DotNetNuke does, to match their userids with data in other tables?

  3. I don't want to find myself dealing with user-tagged data in EF context and solely using the built-in Membership methods for user authentication. Although entering a Membership user for each row to get user information to connect to a column in a GridView seems awkward, is it really what is required? Do I really have to duplicate the Membership classes in EF in order to get data?

  4. I considered adding a membership provider to EF with the hope that it may eventually become a part of the broader EF data architecture. Is this talk crazy? (I've never previously created my own provider.)

Please feel free to correct me if I'm not making sense.

1
10
5/10/2012 10:18:37 AM

Accepted Answer

Why not arrange things in reverse? For Asp.net, you may create your own Membership provider using the model you need or require.

You may just develop your own provider if the functionality you want don't quite match the built-in asp.net membership implementation. Just a few methods must be implemented if just a few features are used; all other methods do not need implementation. Using the membership provider could get in your way if you want more features than it can provide.

5
3/6/2009 9:36:23 PM

Popular Answer

  1. Though we don't map the Membership tables, we do. Don't assume that the SQL membership provider will be used.
  2. Not the DB id, but the user identity is mapped. Important yet subtle. Do not forget that there are more membership suppliers (e.g., domain auth).
  3. Could you please explain the query? Not all membership information will need to be duplicated in your EF model, but you will require a list of recognized identities.
  4. No, it's not insane at all, but it is challenging and maybe needless.


Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow