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

}