c# Fournisseur d'appartenances ASP.NET personnalisé pour une très grande application



sql asp.net-mvc (3)

Je dois trouver une solution d'adhésion pour un très grand site Web. Le site sera construit en utilisant ASP.NET MVC 2 et une base de données MS SQL2008.

Le fournisseur d'adhésion actuel semble être une grosse surcharge, il y a trop de fonctionnalités.

Tout ce que je veux stocker est email / mot de passe et les informations de base du profil telles que Prénom / Nom, Numéro de téléphone. Je n'aurai besoin que de 2 rôles, administrateurs et utilisateurs.

Quelles sont vos recommandations sur ce type de scénario, étant donné que des millions d'utilisateurs peuvent être enregistrés? Qu'est-ce que StackOverflow utilise?

J'ai beaucoup utilisé l'API d'adhésion existante dans le passé et l'ai étendue pour stocker des informations supplémentaires, etc. Mais il existe des tableaux tels que

aspnet_Applications
aspnet_Paths
aspnet_SchemaVersions
aspnet_WebEvent_Events
aspnet_PersonalizationAllUsers
aspnet_PersonalizationPerUser

qui sont extrêmement redondants et je n'ai jamais trouvé d'utilisation pour.

modifier
Juste pour clarifier quelques autres redondances après la réponse de @ drachenstern, il y a aussi des colonnes supplémentaires dont je n'ai pas besoin dans la table Membership / Users, mais qui s'ajouteraient à la charge utile de chaque instruction select / insert.

  1. MobilePIN
  2. PasswordQuestion / PasswordAnswer (Je ferai une récupération de mot de passe par e-mail)
  3. IsApproved (l'utilisateur sera toujours approuvé)
  4. Commentaire
  5. MobileAlias
  6. Nom d'utilisateur / LoweredUsername (ou Email / LoweredEmail) [email EST le nom d'utilisateur donc seulement besoin de 1 d'entre eux]

De plus, j'ai entendu dire que les GUID ne sont pas aussi rapides, et préféreraient avoir des entiers à la place (comme Facebook le fait) qui seraient également exposés publiquement.

Comment puis-je créer mon propre fournisseur d'appartenance , en réutilisant certaines des API d'adhésion (validation, chiffrement de mot de passe, cookie de connexion, etc.) mais uniquement avec des tables qui répondent à mes exigences?

Les liens vers des articles et des implémentations existantes sont les bienvenus, mes recherches sur Google ont donné des exemples très simples.

Merci d'avance
Marko


Answer #1

@ Marko Je peux certainement comprendre que le système d'adhésion standard peut contenir plus de fonctionnalités que vous n'en avez besoin, mais la vérité est que cela ne va vraiment pas d'importance. Il y a des parties du système d'adhésion que vous n'utiliserez pas comme il y a des parties de .Net que vous n'allez pas utiliser. Il y a beaucoup de choses que .Net peut faire que vous n'utiliserez jamais, mais vous n'allez pas passer par .Net et dépouiller cette fonctionnalité êtes-vous? Bien sûr que non. Vous devez vous concentrer sur les choses qui sont importantes pour ce que vous essayez d'accomplir et travailler à partir de là. Ne vous laissez pas entraîner dans la paralysie de l'analyse. Vous allez perdre votre temps, tourner vos roues et ne pas finir avec quelque chose de mieux que ce qui a déjà été créé pour vous. Maintenant, Microsoft se trompe parfois, mais ils obtiennent beaucoup de bonnes choses. Vous n'avez pas à adopter tout ce qu'ils font pour atteindre vos objectifs - vous devez simplement comprendre ce qui est important pour vos besoins.

Quant aux Guids et aux Ints comme clés primaires, laissez-moi vous expliquer quelque chose. Il existe une différence cruciale entre une clé primaire et un index clusterisé. Vous pouvez ajouter une clé primaire ET un index cluster sur des colonnes qui ne font pas partie de la clé primaire! Cela signifie que s'il est plus important d'organiser vos données par un nom (ou quelque chose d'autre), vous pouvez personnaliser votre index cluster afin de refléter exactement ce dont vous avez besoin sans affecter votre clé primaire. Permettez-moi de le dire d'une autre façon - une clé primaire et un index clusterisé ne sont pas un dans le même. J'ai écrit un billet de blog sur la façon d'ajouter un index en cluster, puis une clé primaire à vos tables. L'index clusterisé ordonnera physiquement les lignes de la table comme vous le souhaitez et la clé primaire appliquera l'intégrité dont vous avez besoin. Jetez un oeil à mon blog pour voir exactement comment vous pouvez le faire.

Voici le lien - http://iamdotnetcrazy.blogspot.com/2010/09/primary-keys-do-not-or-should-not-equal.html .

C'est très simple, il suffit d'ajouter l'index clusterisé FIRST, puis d'ajouter la clé primaire SECOND. Cela doit être fait dans cet ordre ou vous ne pourrez pas le faire. Cela suppose, bien sûr, que vous utilisez Sql Server. La plupart des personnes ne s'en rendent pas compte car SQL Server créera un index clusterisé sur votre clé primaire par défaut, mais tout ce que vous avez à faire est d'ajouter l'index cluster puis d'ajouter la clé primaire et vous serez prêt à partir. L'utilisation d'ints comme clé primaire peut devenir TRÈS problématique au fur et à mesure que votre base de données et votre système de serveur évoluent. Je suggère d'utiliser Guids et d'ajouter l'index cluster pour refléter la façon dont vous avez réellement besoin de vos données stockées.

Maintenant, en résumé, je veux juste vous dire d'aller créer quelque chose de grand et ne pas s'enliser avec des détails superficiels qui ne vont pas vous donner assez de gain de performance pour réellement importer. La vie est trop courte. Aussi, n'oubliez pas que votre système ne peut être aussi rapide que son morceau de code le plus lent. Donc, assurez-vous que vous regardez les choses que réellement prendre beaucoup de temps et prendre soin de ceux.

Et encore une chose de plus. Vous ne pouvez pas prendre tout ce que vous voyez sur le Web à leur valeur nominale. La technologie change au fil du temps. Parfois, vous pouvez voir une réponse à une question que quelqu'un a écrite il y a longtemps et qui n'est plus pertinente aujourd'hui. En outre, les gens vont répondre aux questions et vous donner des informations sans avoir réellement testé ce qu'ils disent pour voir si c'est vrai ou non. La meilleure chose que vous pouvez faire pour votre application est de tester le stress très bien. Si vous utilisez ASP.Net MVC, vous pouvez le faire dans vos tests. Une chose que vous pouvez faire est d'ajouter une boucle for qui ajoute des utilisateurs à votre application dans votre test, puis tester les choses. C'est une idée. Il y a d'autres façons. Vous devez juste faire un peu d'effort pour bien concevoir vos tests ou au moins assez bien pour vos besoins.

Bonne chance à toi!


Answer #2

Ma recommandation serait que vous établissiez un point de référence . Ajoutez autant d'enregistrements que vous le pensez en production et soumettez un nombre de requêtes similaire à celui que vous obtiendriez en production et observez les performances de votre environnement.

Je suppose que ce serait OK, les frais généraux dont vous parlez seraient insignifiants.


Answer #3

Le fournisseur d'adhésion actuel semble être une grosse surcharge, il y a trop de fonctionnalités.

Tout ce que je veux stocker est email / mot de passe et les informations de base du profil telles que Prénom / Nom, Numéro de téléphone. Je n'aurai besoin que de 2 rôles, administrateurs et utilisateurs.

Ensuite, utilisez simplement cette partie. Il ne va pas utiliser les pièces que vous n'utilisez pas, et vous constaterez peut-être que vous avez besoin de ces autres pièces sur la route. Les classes sont déjà présentes dans le framework .NET donc vous n'avez pas à fournir de licence ou quoi que ce soit.

La taille de la base de données est assez petite, et si vous le faites, et laissez aspnetdb à elle-même, alors vous ne prenez rien de vos autres bases de données.

Avez-vous une raison impérieuse d'utiliser un composant tiers sur ce qui est déjà dans le cadre?

EDITER :

Il existe également des colonnes supplémentaires dont je n'ai pas besoin dans la table Membership / Users, mais qui s'ajouteraient à la charge utile de chaque instruction select / insert.

MobilePIN PasswordQuestion / PasswordAnswer (Je ferai la récupération de mot de passe par email) IsApproved (l'utilisateur sera toujours approuvé) Commentaire MobileAlias ​​Username / LoweredUsername (ou Email / LoweredEmail) [email EST le nom d'utilisateur donc seulement besoin de 1 d'entre eux]

Cela ressemble à vous essayez de micro-optimiser . Passer des chaînes vides est pratiquement sans coût (d'accord, c'est là, mais vous devez faire un profil pour savoir combien cela vous coûte.Ce ne sera pas beaucoup par utilisateur). Nous n'utilisons pas systématiquement tous ces champs dans nos applications, mais nous utilisons le système d'adhésion sans impact préjudiciable mesurable.

En outre, j'ai entendu dire que Guid ne sont pas si rapides et préféreraient avoir des entiers (comme Facebook), qui seraient également exposés publiquement.

J'ai entendu dire que le cookiemonster aime les cookies. Encore une fois, sans profilage, vous ne savez pas si c'est préjudiciable. Habituellement, les utilisateurs utilisent des GUID parce qu'ils veulent que ce soit absolument (bien à un degré d'absolu) unique, peu importe quand il est créé. Le coût de la générer une fois par utilisateur n'est pas si lourd. Pas quand vous créez déjà un nouveau compte.

Puisque vous êtes absolument décidé à créer un MembershipProvider à partir de zéro, voici quelques références:

http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx

http://www.4guysfromrolla.com/articles/120705-1.aspx

http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx

http://www.amazon.com/ASP-NET-3-5-Unleashed-Stephen-Walther/dp/0672330113

Stephen Walther va dans les détails dans son livre et c'est une bonne référence pour vous.





asp.net-membership