CODEWITHSUNDEEP
c#asp.net-mvc
Lee
Lee

Reputation: 353

How to properly inherited ASP.net MembershipUser with DB table persistence

I'm working with a custom membership provider. I'm also using a membership class that is inheriting and extending MembershipUser.

My question comes from creating a user and saving to the DB. When I observe the DB, I only find the following columns with correct data. The remaining properties are not listed within the columns.

  1. id
  2. test
  3. Email
  4. Comment
  5. IsApproved
  6. LastLoginDate
  7. LastActivityDate

What is happening and how do I correct this to include the remaining properties?

The membership class looks something like this:

public class MyMembershipUser : MembershipUser
{ public MyMembershipUser(string providerName,
            string name,
            Object providerUserKey,
            string email,
            string passwordQuestion,
            string comment,
            bool isApproved,
            bool isLockedOut,
            DateTime creationDate,
            DateTime lastLoginDate,
            DateTime lastActivityDate,
            DateTime lastPasswordChangedDate,
            DateTime lastLockoutDate) :
        base(providerName, name, providerUserKey, email,
                passwordQuestion, comment,
                isApproved, isLockedOut,
                creationDate, lastLoginDate,
                lastActivityDate, lastPasswordChangedDate,
                lastLockoutDate)
    {
    }

    [Key]
    public int Id { get; set; }

    public string test { get; set; }
}

:

My Creation is as follows:

MyMembershipUser usr = new MyMembershipUser(.......);
dbcontext.users.Add(usr);
dbcontext.SaveChanges();

Edited............

Further research as brought me to the following understanding of the relationship between the definition of MembershipUser and the functionality I'm seeing.

email                   -   virtual get; set    -  Stored in DB
comment                 -   virtual get; set    -  Stored in DB
isApproved              -   virtual get; set    -  Stored in DB
lastLoginDate           -   virtual get; set    -  Stored in DB
lastActivityDate        -   virtual get; set    -  Stored in DB
Username                -   virtual get         -  Not Stored
providerName            -   virtual get         -  Not Stored 
providerUserKey         -   virtual get         -  Not Stored
passwordQuestion        -   virtual get         -  Not Stored
isLockedOut             -   virtual get         -  Not Stored
creationDate            -   virtual get         -  Not Stored
lastPasswordChangedDate -   virtual get         -  Not Stored
lastLockoutDate         -   virtual get         -  Not Stored

After the constructor, all of the values are initialized and available, so there is some storage in the base class; however, since some of them are not in the DB table, later retrieval isn't available for those properties. From this, I ascertain that I have to implement my own persistence. How can I do this in the MyMembershipUser model without conflicting with the base class properties?

For a quick test I tried the following without success. base.PasswordQuestion is read only.

public virtual string PasswordQuestion {
    get {
        return base.PasswordQuestion;
    }
    set {
        base.PasswordQuestion = value;
    }
}

I must be travelling out in left field. What good are these values if they can't be updated and stored. In summary they are not in the table, I can't get them there, I can't update them, and I can't store them without going about some side route that I'm sure is not the original intention.

Can someone point me in the right direction.

Upvotes: 1

Views: 341

Answers (1)

Lee
Lee

Reputation: 353

I finally figured out how to get it to work. I had to override the get/set for the get/read-only properties that were not being stored in the DB. Then, in the constructor, set these properties to the incoming values.

This is like re-implementing the entire class. IMHO, this makes the MembershipUser class much like an interface than that doesn't actually do anything but represent values. Again, IMHO, I think MS kinda dropped the ball on different areas of MVC and asp.net. Where is the simple and basic user base class with just a username and password. Where is the hierarchy and re-usability that is preached so hard about designs. Maybe it is because I'm still fairly new to MVC and asp.net. Maybe I'm just spoiled from other languages and libraries.

In either case, I've found a workable solution. Basically inherit MembershipUser. Override the get properties that are desired to keep in the DB. Add the sets for these properties. Those that are stored (with base get/set) are good as is. Now I have a class that can be down cast to a MembershipUser type.

Upvotes: 1

Related Questions