Usage and views on membership role profile provider

Without the temptation of Microsoft, we finally adopted the standard ASP. NET 2.0 membership role profile solution in the new project. However, it is difficult to use t_t in use. It took one week to implement it and apply it. However, it was very difficult to use it, especially to obtain the user's extended information and complexity. Finally, I switched back to my familiar isecurity solution (see below). Haha, it took only one afternoon to change back to the original solution, and the code is refreshing: The following are my views on this standard provider solution:

Roleprovider is used to provide user role information. Well designed, with no redundancy.
Membershipprovider is used for user authentication, verification, login, and cancellation. Field redundancy and interface redundancy are not always used.
Profileprovider is used to save user extension information. Implementation and its complexity are really annoying...

In general, this solution involves user authentication, role, and user extension information. It is a set of "seemingly perfect" solutions. However, after a thorough trial, we found that, apart from roleprovider, this solution was suspected of being overly-designed. Interface functions are highly redundant and difficult to expand. They need to use countless related classes. Generally, I only use these several interface functions for authentication and role acquisition:

Membershipprovider. validateuser (...)
Roleprovider. getallroles (...)
Roleprovider. getrolesforuser (...)
Roleprovider. adduserstoroles (...)

As for profileprovider, it is intended to save the user's extended information, but its structure design causes the database to be difficult and inefficient in batch query, and the interface code is extremely complex, it is very complicated to implement, and it is really hard to mention the idea of using it @_@. Do you have any good suggestions or methods (especially the methods for saving user extended information)? Please kindly advise. As for roleprovider, although there is no redundancy, it is far from enough for single-use. For example, the interface function: String [] getusersforrole (string role) Only returns a string array, and user information cannot be directly returned. You need to use membership and profile again to obtain extension information, which cannot be put in place at one time. This is also true for membership. We are used to using two fields to store the user information: account and name. membership only provides the username attribute. If you want to obtain the user list in batches, including the user account and name. How can this problem be solved? Get the account first, and then use profiile to get the name? Thoroughly dizzy ..... in addition, the worst thing is that this solution is in the system. what is implemented in the Web namespace is added with the processing logic under the web, which is not universal. It is invalid when a Windows program is created @! # % $ # % @ # $ @....

I have abandoned this standard recommendation solution. The following is a user role authentication solution used in my current project. It is easy to use and serves as your reference. In addition, do you think that the larger the design of. Net class libraries, the more out of control (How many collection classes can be replaced by ilist <t> ?)? The design principle of the class library should be general and simplified, and not all functions should be stacked up .... at least, the extended and not all required classes and interfaces should not go to system. DLL, system. web. plug in the DLL .....

/// <Summary>
/// Security interface: User, role, resource, Authentication
/// </Summary>
Public interface isecurity <t>: idisposable where T: iuserinfo
{
// Init
Void initialize (Params string [] config );

// Authenticate
Bool validateuser (string userid, string password );

// Create user object
T createuserobject ();

// User
List <t> getusers (Params string [] parameters );
T getuser (string userid );
Void createuser (ref T User );
Void updateuser (ref T User );
Void deleteuser (string userid );

// Role
String [] getallroles ();
String [] getrolesforuser (string userid );
List <t> getusersinrole (string role );
Bool isuserinrole (string userid, string role );
Void addusertoroles (string userid, string [] roles );
Void removeuserfromroles (string userid, string [] roles );

// Resources
// String [] getallresources ();
// String [] getresourcesforuser (string userid );
// String [] getusersinresource (string resource );
}

/// <Summary>
/// Basic user information interface
/// </Summary>
Public interface iuserinfo
{
String userid {Get; set ;}
String username {Get; set ;}
String password {Get; set ;}
String Organization {Get; set ;}
String comment {Get; set ;}
String status {Get; set ;}
Void clone (iuserinfo user );
}

You only need to implement the isecurity and iuserinfo interfaces for each application.