Profil utilisateur intégré ASP.NET par rapport aux anciennes classes/tables d'utilisateurs

Je recherche des conseils concernant les meilleures pratiques concernant l'utilisation de la fonctionnalité de profil dans ASP.NET.

Comment décidez-vous ce qui doit être conservé dans le profil utilisateur intégré, ou si vous devez créer votre propre table de base de données et ajouter une colonne pour les champs souhaités ? Par exemple, un utilisateur a un code postal, dois-je enregistrer le code postal dans ma propre table, ou dois-je l'ajouter au profil web.config xml et y accéder via le mécanisme ASP.NET du profil utilisateur ?

Les avantages/inconvénients auxquels je peux penser en ce moment sont que puisque je ne connais pas très bien le profil (c'est un peu une matrice en ce moment), je peux probablement faire tout ce que je veux si j'emprunte la route de la table (par exemple, SQL pour obtenir tous les utilisateurs dans le même code postal que l'utilisateur actuel). Je ne sais pas si je peux faire la même chose si j'utilise le profil ASP.NET.

请先 登录 后评论

4 réponses

Dan

D'après mon expérience, il est préférable de garder les informations dans le profil au strict minimum, n'y mettre que les éléments essentiels qui sont directement nécessaires à l'authentification. D'autres informations telles que les adresses doivent être enregistrées dans votre propre base de données par votre propre logique d'application, cette approche est plus extensible et maintenable.

请先 登录 后评论
Chris Newman

Je n'ai construit que 2 applications utilisant le fournisseur de profil. Depuis, je ne l'utilise plus. Pour les deux applications, je l'ai utilisé pour stocker des informations sur l'utilisateur telles que le nom de sa société, son adresse et son numéro de téléphone.

Cela fonctionnait bien jusqu'à ce que notre client veuille pouvoir trouver un utilisateur par l'un de ces champs. La recherche impliquait de parcourir chaque profil d'utilisateur et de comparer les informations aux critères de recherche. Au fur et à mesure que la base d'utilisateurs augmentait, le temps de recherche devenait inacceptable pour notre client. La seule solution était de créer une table pour stocker les informations des utilisateurs. La vitesse de recherche a été considérablement augmentée.

Je recommanderais de stocker ce type d'informations dans sa propre table.

请先 登录 后评论
D.J

le profil utilisateur est un cadre propre et agréable pour la personnalisation individuelle (AKA. Profile Properties). (par exemple, iGoogle) le problème est qu'il n'est pas conçu pour les requêtes et qu'il n'est pas idéal pour le partage de données avec un utilisateur public. (vous pourriez toujours le faire, avec de faibles performances)

donc, si vous souhaitez améliorer l'expérience utilisateur personnalisée, le profil utilisateur serait une bonne solution. sinon, utiliser votre propre classe et table serait une bien meilleure solution.

请先 登录 后评论
Simon_Weaver

Je pense qu'il est préférable de l'utiliser pour des données supplémentaires qui ne sont pas critiques pour l'utilisateur et qui ne sont normalement importantes que lorsque cet utilisateur se connecte de toute façon. Pensez à des données qui ne briseraient rien d'important si elles étaient toutes effacées.

Bien sûr, c'est une préférence personnelle, mais d'autres ont soulevé d'autres problèmes importants.

Également très utile étant donné qu'il peut être utilisé pour un utilisateur non authentifié dont le profil est maintenu avec un cookie anonyme.

请先 登录 后评论