ASP.NET: Custom MembershipProvider avec une table utilisateur personnalisée

Question

J'ai récemment commencé à bricoler avec ASP.NET MVC, mais cette question devrait s'appliquer à ASP.NET classique aussi bien. Pour ce que ça vaut, je ne sais pas beaucoup sur les formes des fournisseurs d'authentification et d'adhésion soit.

Je suis en train d'écrire mon propre MembershipProvider qui sera connecté à ma propre table utilisateur personnalisé dans ma base de données. Ma table utilisateur contient toutes les informations utilisateur de base tels que les noms d'utilisateur, mots de passe, des sels de mot de passe, les adresses e-mail et ainsi de suite, mais aussi des informations telles que le prénom, le nom et le pays de résidence.

Pour autant que je comprends, la manière standard de faire cela dans ASP.NET est de créer une table utilisateur sans les informations supplémentaires et une table « de profil » avec les informations supplémentaires. Toutefois, cela ne semble pas très bon pour moi, parce que chaque fois que je besoin d'accéder à ces informations supplémentaires je dois faire une requête de base de données supplémentaire pour l'obtenir.

Je lis dans le livre « Pro ASP.NET 3.5 C # 2008 » qui ayant une table séparée pour les profils ne sont pas une très bonne idée si vous avez besoin d'accéder à la table de profil beaucoup et ont de nombreuses pages différentes dans votre site Web .

Maintenant le problème à portée de main ... Comme je l'ai dit, j'écris ma propre sous-classe MembershipProvider personnalisé et ça va assez bien jusqu'à présent, mais maintenant je suis venu à réaliser que le CreateUser ne me permet pas de créer des utilisateurs dans la façon dont je voudrais. La seule méthode prend un nombre fixe d'arguments et prénom, nom et pays de résidence ne font pas partie d'entre eux.

Alors, comment pourrais-je créer une entrée pour le nouvel utilisateur dans mon tableau personnalisé sans cette information à portée de main dans CreateUser de mon MembershipProvider?

Answer 1

Je pense que vous devriez aller avec votre approche et ajouter une nouvelle fonction dans votre mise en œuvre, je veux dire, surcharger la méthode CreateUser et un CustomMembershipUser (qui étend la MembershipUser) en tant que paramètre. De cette façon, avant d'utiliser le fournisseur, le jeter à votre CustomMembershipProvider et utiliser la méthode surchargée.

Answer 2

Je suis d'accord avec votre analyse que vous devez garder à la fois l'adhésion et des informations de profil dans la même table. Puisque vous avez raison que vous êtes limité par le nombre de paramètres qui prend CreateUser, vous devez concevoir votre domaine afin que les attributs de profil non-membres sont annulable. Cela ne signifie pas que vous aurez champs obligatoires qui sont nulles dans la base de données, cependant. Au lieu de cela, vous pouvez vous le ci-dessous extrait:

string username = .../ retrieve username here

Membership.CreateUser(username , password, email);

ProfileBase newProfile = Profile.Create(username); //since the user has just been created, all properties will be blank

//set all entered properties
newProfile.SetPropertyValue("MyProp1", myProp1Value);
... 
newProfile.SetPropertyValue("MyPropN", myPropNValue);

newProfile.Save();

De cette façon, vous tirez parti des fournisseurs d'adhésion de ASP.NET pour créer l'utilisateur et enregistrer les données de profil, mais à votre utilisateur final il est une seule opération atomique.