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

Je suis à la recherche de conseils sur les meilleures pratiques concernant l'utilisation de la fonctionnalité 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, devrais-je enregistrer le code postal dans ma propre table, ou dois-je l'ajouter au profil xml web.config et y accéder via le mécanisme ASP.NET du profil utilisateur?

Les avantages / inconvénients que je peux penser maintenant sont que puisque je ne connais pas très bien le profil (c'est un peu un Matrix en ce moment), je peux probablement faire ce que je veux si je aller sur la route de 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.

0

5 Réponses

Je pense que cela dépend du nombre de champs dont vous avez besoin. À ma connaissance, les profils sont essentiellement une longue chaîne qui se scinde à la taille des champs donnés, ce qui signifie qu'ils ne se transforment pas très bien si vous avez beaucoup de champs et d'utilisateurs.

D'un autre côté, ils sont intégrés, c'est donc un moyen facile et standardisé, ce qui signifie qu'il n'y a pas de grande courbe d'apprentissage et que vous pouvez également l'utiliser dans les futures applications sans avoir à modifier la structure d'une table.

Rouler votre propre chose vous permet de le mettre dans une base de données correctement normalisée, ce qui améliore considérablement les performances, mais vous devez écrire à peu près tout le code de gestion de profil vous-même.

Editer: De plus, les profils ne sont pas mis en cache, donc chaque accès à un profil va d'abord à la base de données (il est ensuite mis en cache pour cette requête, mais la requête suivante l'obtiendra de la base de données)

Si vous songez à écrire votre propre truc, peut-être un Le fournisseur de profil personnalisé vous offre le meilleur des deux mondes - l'intégration transparente, mais les tâches personnalisées que vous voulez faire.

0
ajouté

Dans mon expérience, il est préférable de garder les informations dans le profil au strict minimum, seulement mettre les éléments essentiels qui sont directement nécessaires pour 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.

0
ajouté
> D'autres informations telles que les adresses doivent être sauvegardées dans votre propre base de données par votre propre logique d'application OK, donc cela semble être le chemin à parcourir, quelqu'un peut-il me dire comment lier les tables asp_ user à cette nouvelle table? devrais-je utiliser le userName dans la table asp_ comme le lien, l'userID (ce guid laid que je ne sais pas comment obtenir) ou quoi?
ajouté l'auteur csmba, source
Vous pouvez également lancer votre propre table utilisateur qui contiendrait les mêmes informations, puis utiliser des variables de session ou quelque chose de similaire, dans ce cas vous auriez un contrôle total. Je suis passé à mes propres tables d'utilisateurs cette fois et je ne le regrette pas.
ajouté l'auteur Sean, source

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 aux données qui ne casseraient rien d'important si tout était effacé.

Bien sûr, c'est une préférence personnelle, mais d'autres ont soulevé d'autres questions importantes.

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

0
ajouté

Le profil d'utilisateur est un cadre propre et agréable pour la personnalisation individuelle (AKA, Profile Properties). (par exemple, iGoogle) le problème de ce n'est pas conçu pour la requête et pas idéal pour le partage de données à l'utilisateur public (vous seriez toujours capable de le faire, avec une faible performance)

Donc, si vous voulez améliorer l'expérience utilisateur personnalisée, le profil de l'utilisateur serait un bon moyen d'aller. sinon, utilisez votre propre classe et table serait une bien meilleure solution.

0
ajouté

J'ai seulement construit 2 applications qui utilisaient le fournisseur de profil. Depuis lors, je suis resté loin de l'utiliser. Pour les deux applications, je l'ai utilisé pour stocker des informations sur l'utilisateur tels que le nom de l'entreprise, l'adresse et le numéro de téléphone.

Cela a bien fonctionné jusqu'à ce que notre client voulait pouvoir trouver un utilisateur par l'un de ces champs. La recherche impliquait de parcourir le tous les profils d'utilisateurs et de comparer les informations aux critères de recherche. À mesure que la base d'utilisateurs grandissait, le temps de recherche devenait inacceptable pour notre client. La seule solution consistait à créer une table pour stocker les informations des utilisateurs. La vitesse de recherche a été augmentée énormément.

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

0
ajouté