Design of users and profiles (MebershipUser etc.)

[rohde]

I'm in need of some advice. I'm in the process of designing an ASP.NET
application. The site will need to accomodate three very different
types of users. Each type of user will have different properties
associated with it, and each will basically map to a role.

I'm considering how to best do this with the role/membership feature
of ASP.NET.

I was first contemplating inheriting from MembershipUser, i.e. create
three classes that inherited from MembershipUser (one for each kind of
I user), but as far I understand it that means I will have to provide
three provider classes each inheriting from MembershipProvder,
resulting in me having to dynamically change provider at runtime, and
that seems very convoluted and far from optimal.

Instead I've come to the conclusion that I'll use composition instead.
The idea is to create three user classes, each of which has a
MembershipUser object reference in their belly. It seems much cleaner
and leaner.

But, any advice/experience on this?

[clintonG]

At the moment it sounds as if you're going over-board. Why not describe the
actual criteria of the roles so anybody that wants to respond can do so
intelligently.

I've looked and looked and nowhere in the framework can I find the
MindReader namespace...

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
"rohde" <ro*******@gmail.comwrote in message
news:11**********************@g4g2000hsf.googlegro ups.com...

I'm in need of some advice. I'm in the process of designing an ASP.NET
application. The site will need to accomodate three very different
types of users. Each type of user will have different properties
associated with it, and each will basically map to a role.

I'm considering how to best do this with the role/membership feature
of ASP.NET.

I was first contemplating inheriting from MembershipUser, i.e. create
three classes that inherited from MembershipUser (one for each kind of
I user), but as far I understand it that means I will have to provide
three provider classes each inheriting from MembershipProvder,
resulting in me having to dynamically change provider at runtime, and
that seems very convoluted and far from optimal.

Instead I've come to the conclusion that I'll use composition instead.
The idea is to create three user classes, each of which has a
MembershipUser object reference in their belly. It seems much cleaner
and leaner.

But, any advice/experience on this?

[rohde]

On 21 Jun., 15:56, "clintonG" <[e-mail]:

At the moment it sounds as if you're going over-board. Why not describe the
actual criteria of the roles so anybody that wants to respond can do so
intelligently.

Uhm, well the actual attributes of the different types of users can't
really be important. The problem is that I basically will need to
create three sub tables of the main Users table, each holding the
different attributes of the three kinds of users.

So my question really is what would be the most advantageous way to
build this into the Membersip part of ASP.NET business object wise.

>
I've looked and looked and nowhere in the framework can I find the
MindReader namespace...

Oh it's coming in .NET 5.4 :)

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URLhttp://clintongallagher.metromilwaukee.com/

"rohde" <[e-mail] in message

news:11**********************@g4g2000hsf.googlegro ups.com...

I'm in need of some advice. I'm in the process of designing an ASP.NET
application. The site will need to accomodate three very different
types of users. Each type of user will have different properties
associated with it, and each will basically map to a role.

I'm considering how to best do this with the role/membership feature
of ASP.NET.

I was first contemplating inheriting from MembershipUser, i.e. create
three classes that inherited from MembershipUser (one for each kind of
I user), but as far I understand it that means I will have to provide
three provider classes each inheriting from MembershipProvder,
resulting in me having to dynamically change provider at runtime, and
that seems very convoluted and far from optimal.

Instead I've come to the conclusion that I'll use composition instead.
The idea is to create three user classes, each of which has a
MembershipUser object reference in their belly. It seems much cleaner
and leaner.

But, any advice/experience on this?

[sloan]

I have no idea if this will help you or not.

But
http://www.dofactory.com/Patterns/PatternDecorator.aspx

Decorator Pattern.

I'd also get the HeadFirst Book on Design Patterns. I think their duck
example is pretty good.

...
"rohde" <ro*******@gmail.comwrote in message
news:11**********************@g4g2000hsf.googlegro ups.com...

I'm in need of some advice. I'm in the process of designing an ASP.NET
application. The site will need to accomodate three very different
types of users. Each type of user will have different properties
associated with it, and each will basically map to a role.

I'm considering how to best do this with the role/membership feature
of ASP.NET.

I was first contemplating inheriting from MembershipUser, i.e. create
three classes that inherited from MembershipUser (one for each kind of
I user), but as far I understand it that means I will have to provide
three provider classes each inheriting from MembershipProvder,
resulting in me having to dynamically change provider at runtime, and
that seems very convoluted and far from optimal.

Instead I've come to the conclusion that I'll use composition instead.
The idea is to create three user classes, each of which has a
MembershipUser object reference in their belly. It seems much cleaner
and leaner.

But, any advice/experience on this?

[rohde]

On 21 Jun., 16:58, "sloan" <[e-mail]:

I have no idea if this will help you or not.

Buthttp://www.dofactory.com/Patterns/PatternDecorator.aspx

Decorator Pattern.

I've just looked up the Decorator Pattern in the gang of four book,
and it's actually what I had in mind doing originally. So yes, that's
a good idea :)

[sloan]

I thought the idea was worthy.

I just don't know first hand if you can actually match it up to your need.

Give her the ole' college try I guess!

"rohde" <ro*******@gmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...

On 21 Jun., 16:58, "sloan" <[e-mail]:

I have no idea if this will help you or not.

Buthttp://www.dofactory.com/Patterns/PatternDecorator.aspx

Decorator Pattern.

I've just looked up the Decorator Pattern in the gang of four book,
and it's actually what I had in mind doing originally. So yes, that's
a good idea :)