CODEWITHSUNDEEP
c#.netasp.net-mvcasp.net-membership
harman_kardon
harman_kardon

Reputation: 1717

Should my User model inherit MembershipUser

I'm looking at creating a custom membership provider in ASP.Net MVC3 and am struggling to see how it all fits together...

I'm really looking for some best practice approaches on how to do this.

I have a User model (represnting a Users table in my database). In order to use this with the MembershipProvider functionality, should this model inherit MembershipUser? There are a number of fields in MembershipUser that I do not care about - do these have to be in the underlying SQL table for this approach to work (obviously this seems redundant, as I'll never use the columns?)

For example - should I make my model inherit MembershipUser like this?

/// <summary>
/// Class representing a registered user based on the Users database table.
/// </summary>
public class User : MembershipUser
{
    public int Id { get; set; }
    //here I can access some other properties I will use which are already in MembershipUser...

    //Addtional properties I need specific to my app.
    public bool NotifyOfNewBlog { get; set; }
    public bool NotifyOfNewWallPosts { get; set; }
    //...plus many more.
}

When it comes to using Membership.GetUser() further down the line, do I then cast that object everytime back to my original User object to be able to access the additional properties?

Is this the approach I should be taking? Or do I a separate User model and then a CustomMembershipUser model which links back to the DB model?

Will EF be able to save/update/insert a User model if it doesn't have all the MembershipUser columns as objects in the table? Is this even anywhere near the correct approach? As you can see, I'm scratching my head a bit here.

Any advice/thoughts/ideas are much appreciated.

Upvotes: 2

Views: 577

Answers (2)

WDRust
WDRust

Reputation: 3713

I had quite the same problem a while ago, and in the end i decided not to pollute my EF models with Membership logic. I have my data access tier in my application, and my EFMembershipProvider use that when he has to save/update data. If i have to GET user data in my application (other than in the membership itself), i don't use Membership (and i don't have to cast nothing).

I want to make clear that if you implement your own Membership Provider

public class EFMembershipProvider : MembershipProvider

you can abstract the underlying functionality of the membership facility to use your own models/repositories.

You can find an example of an implemented membership provider for EF in the MVC3 boilerplate

https://github.com/crdeutsch/MVC3-Boilerplate

Under Web/Infrastructure (though you probably want to modify large parts of it).

Upvotes: 1

AaronHS
AaronHS

Reputation: 1352

As far as inheriting the MembershipUser object goes, you could do that, and in your implementation of MembershipProvider, just cast up to your derived type, but I personally would not do this, simply because you are then at the mercy of future changes to this type breaking your derived type (although this could be said about most of the framework I guess). I would instead put these additional values into a profile, and roll your own ProfileProvider, (don't use the Sql one it is rubbish from my experience).

"There are a number of fields in MembershipUser that I do not care about - do these have to be in the underlying SQL table for this approach to work (obviously this seems redundant, as I'll never use the columns?)"

If you are rolling your own, you can just not save this in the Db. After all, you are implementing the MembershipProvider methods (GetUser etc etc) so what you do with the MembershipUser object passed to you, is up to you. You can just ignore these, and not validate or store them.

Upvotes: 1

Related Questions