Speculating about Membership, RoleProvider and ProfileAPI implementation
There's an important area in ASP.NET Whidbey that I've started looking into
that I haven't seen much coverage on, that is, how will the new user/security
features be used when building a real application?
Membership, RoleProvider and ProfileAPI are the 3 that I'm talking about
here.
Membership has some great features for managing users such as creating,
retrieving, updating and deleting user There's also a MembershipUser class
which contains some of the instance data for users such as username, email,
etc.
The ProfileAPI allows you to store additional arbitrary pieces of data
against a MembershipUser.
So, from this you can see that there is a disjoint between all of the user
information with some of it stored in the MembershipUser class and the remainder
(aside from roles) stored in the Profile class.
Writing a wrapper around Membership, RoleProvider and
ProfileAPI
In doing some speculative thinking over the weekend to try and envisage how
these classes will get used, I imagined that you would need to create a "User"
class to unify that data. For example, I'd imagine that you wouldn't want
to be passing System.Web.Membership.MembershipUser's out of your web
services.
So, in-line with the starter kit architecture of today, I would imagine that
some sort of User and UserBL classes may get written to unify access to User
data.
class UserBL {
public static bool ValidateUser(MyApplicationUser u) { return Membership.ValidateUser( ... ) }
public static MyApplicationUser GetUser(string username) {
MembershipUser tmp = Membership.GetUser( ... )
MyApplicationUser usr = new MyApplicationUser()
// read in all values from MembershipUser
usr.prop = tmp.prop
// add values from Profile
usr.prop = Profile.prop
return usr
}
... etc
}