Comment implémenter le fournisseur d'appartenance ASP.NET dans mon modèle de domaine

Question

Sur un site Web, je dois intégrer l'adhésion et l'authentification. Je souhaite donc utiliser les fonctionnalités de l'appartenance à ASP.NET, mais j'ai d'autres éléments personnalisés, à savoir un "utilisateur". a a faire.

Je suis donc assis ici avec mon crayon et du papier, en train de tracer des lignes pour mon modèle de domaine ... Et comment puis-je utiliser au mieux l'abonnement ASP.Net tout en l'étendant pour répondre à mes besoins?

Devrais-je créer une classe qui hérite d'un MembershipUser et l'étendre avec mes propres propriétés et méthodes (et l'enregistrer dans une table séparée). Ou devrais-je laisser MembershipUser être une propriété de mon objet utilisateur / client personnalisé?

Quel serait un bon moyen solide de le faire?

Answer 1

J'y ai réfléchi et il y a deux manières qui semblent appropriées (bien sûr, il y a plus de façons de le faire fonctionner).

Fournisseur d'adhésion personnalisé

Vous changez le fournisseur d'appartenance pour utiliser le vôtre et utilisez votre objet Utilisateur pour stocker toutes les informations.

Le problème avec celui-ci est qu’il implique beaucoup de réimplémentation de choses déjà bien gérées par Asp.Net. La bonne chose est que vous avez un seul objet utilisateur avec tous les détails.

Lien d'un utilisateur membre vers votre utilisateur

Avec cette méthode, vous utiliseriez le fournisseur d'adhésion d'origine pour gérer le nom d'utilisateur et le mot de passe, mais vous liez votre propre objet Utilisateur à celui-ci avec un nom similaire à celui de l'utilisateur, par exemple à l'aide d'un service.

Il est très facile à configurer, il vous suffit de créer un service qui serait utilisé comme ceci:

string userName = "Jon Skeet";
User user = new UserManagementServices().GetUserByUserName(userName);

Answer 2

J'ai fini par écrire mon propre fournisseur d'adhésion et l'ai implémenté dans 3 solutions distinctes maintenant. C’est extrêmement simple et bien plus élégant que de lier un utilisateur à un utilisateur (que j’ai aussi essayé).

Lisez ceci ...:

Créer un fournisseur d'abonnement personnalisé pour la sécurité du site Web ASP.NET

Et si vous souhaitez en savoir plus, regardez cette vidéo (avec code source) .

Answer 3

J'ai étendu MembershipUser et créé ma propre version de SqlMembershipProvider pour le mapper sur mon domaine existant et son bon fonctionnement en production.

MembershipUser est essentiellement une vue sur ma table User. Ma classe d'appartenance étendue UserUser inclut des propriétés de style profil / compte au lieu d'utiliser le système SqlProfileProvider par défaut, ce qui est un peu fragile.

Je n'ai pas pu utiliser les tables d'appartenance ou les sprocs existants, mais j'ai écrit le mien. Par exemple, SqlMembershipProvider utilise un GUID en tant que clé opaque, mais le système de production utilise un simple ancien int. Toutes les dates sont également au format UTC, etc.

Toutes les fonctionnalités utilisateur supplémentaires sont accessibles via le domaine Utilisateur et non via les méthodes d'appartenance.

HTH.

Answer 4

Je travaille actuellement sur l'API d'adhésion à Microsoft ASP.NET 2.0. Article étendu du magazine CoDe qui explique comment étendre l'API d'adhésion en écrivant un wrapper autour des classes existantes. Le principal avantage est que vous pouvez conserver toutes les fonctionnalités prêtes à l'emploi et ne pas devoir réécrire les vôtres comme vous le feriez lors de la mise en œuvre d'un fournisseur personnalisé. Le code source est fourni.