R – How to get the current user equivalent to an aspnet_User object

asp.netasp.net-membershipauthenticationentity-frameworkforeign-keys

My table, AccLink, has a foreign key, UserId, to the aspnet_User table created by the Membership Provider.

When creating an object of type AccLink (I'm using the entity framework) I need to assign the aspnet_User by getting the current user object.

I tried Membership.GetUser(userName) but it said it couldn't be converted to type aspnet_User. What is equivalent to the model built by the entity framework that I can use to assign to the AccLink object?

Best Answer

I think the only way is to get an aspnet_User object from the database (e.g. select by user name or email or some unique info you get from MembershipUser)

Related Solutions

Sql-server – How to foreign key constraints be temporarily disabled using T-SQL

If you want to disable all constraints in the database just run this code:

-- disable all constraints
EXEC sp_MSforeachtable "ALTER TABLE ? NOCHECK CONSTRAINT all"

To switch them back on, run: (the print is optional of course and it is just listing the tables)

-- enable all constraints
exec sp_MSforeachtable @command1="print '?'", @command2="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all"

I find it useful when populating data from one database to another. It is much better approach than dropping constraints. As you mentioned it comes handy when dropping all the data in the database and repopulating it (say in test environment).

If you are deleting all the data you may find this solution to be helpful.

Also sometimes it is handy to disable all triggers as well, you can see the complete solution here.

R – How would you use Entity Framework (1.0) with ASP.Net Membership

My advice is: "Don't."

Let me be more specific.

Using UserId as a mapped, foreign key ties your entity model not to ASP.NET Membership in general, but to the SQL Membership Provider in general. What happens if you then want to use domain authentication or OpenID?

Don't get me wrong: 99.9% of the time it's correct to tie DB references together with a foreign key. Heck, you could even do it here, but don't map it into your entity model. You need to keep a wall of logical separation between membership providers and your own data. You access your data through the EF. You access membership data through the membership API. The fact that they happen to live in the same DB because you happen to be using the SQL membership provider is an implementation detail.

Update: I've expanded upon this idea in a blog post.

Best Answer

Related Solutions

Sql-server – How to foreign key constraints be temporarily disabled using T-SQL

R – How would you use Entity Framework (1.0) with ASP.Net Membership

Related Topic