Membership when more info is needed for a User

[Savvoulidis Iordanis]

I use SQL Server Membership provider and my data are also stored in SQL
Server. But the default user fields are not enough for my users info. So I
created another Users table apart from aspnet_Membership. It has a
PK(uniqueidentifier) to create the reference to aspnet_Membership table and
my other info columns.
Having read about the Custom Membership Provider in .NET help, it says that
I should create a new object inherited from MembershipProvider and rewrite
all of its methods so it can be used by the membership system calls.
The question is:
Why not inherit from SQLMembershipProvider instead of MembershipProvider?
That way, most of the methods are already implemented and the only thing I
would do is to override the CreateUser, UpdateUser, GetUser methods, that is,
only a few
.. In the 1st line of the overriden methods, I could use Mybase.CreateUser,
Mybase.UpdateUser and so on, and just add the rest of the stuff I want to do
to deal with my extra info.
Am i in the right direction? I'd like a comment.

TIA
Iordanis

 

[sloan]

You should look first at the Profile to see if its enough to help you.


http://odetocode.com/Articles/440.aspx


If you're using SqlServer, you ~can~ inherit from
SQLMembershipProvider.

Not everyone uses sql server obviously.

 

[Savvoulidis Iordanis]

It doesn't. Only users with specific roles need to store extra info

 

[Junior]

The use of the MembershipProvider is tightly integrated with Roles. You want
to look at the Profile Table Provider ScottGu released after the Provider
model intially released was found to be FUBAR.

 

[Savvoulidis Iordanis]

I also need the roles system. Also I studied it Scott Guthrie's work.
Although it is very nice explained, I think I would give it a thumbs down.
I'd prefer it if the profile table was generic and with fixed columns, and
the profile properties were records in that table. Dealing with the property
types, can be handled by examining the value_type field. I have done this
project in the past, and it works like a charm and that's what I want to do
now.
(starting a parenthesis here)

Table OPTIONS(userId, name, option_group_name, label, value, value_type,
value_mask, SQL_needed, lower_limit, upper_limit, date_changed, comments,
sort_order)

That way, no changes are made to the table and stored procedures, when a new
option is added or deleted. I'd like a comment on that, by Scott Guthrie if
he sees this post. By the way, I very much like the way he explains his work,
as I study it now and then. We need guys like him. (end of parenthesis).

Going back to the membership issue, what I need is:
If I inherit from the SqlMembershipProvider in order to just override some
methods to add more info to my users, will the membership system be able to
call my new overriden methods? I wouldn't like to rewrite the whole
MemberShip provider from scratch by inheriting from MemberShipProvider class.

TIA