R
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?
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?