Provider di appartenenze personalizzate ASP.NET per applicazioni molto grandi

Question

Devo trovare una soluzione di abbonamento per un sito Web di grandi dimensioni. Il sito verrà creato utilizzando ASP.NET MVC 2 e un database MS SQL2008.

L'attuale provider di appartenenze sembra un grande overkill, c'è troppa funzionalità.

Tutto quello che voglio memorizzare è email/password e informazioni di base del profilo come First/LastName, numero di telefono. Avrò sempre e solo bisogno di 2 ruoli, gli amministratori & utenti.

Quali sono i tuoi consigli su questo tipo di scenario, considerando che potrebbero esserci milioni di utenti registrati? Che cosa usa StackOverflow?

Ho usato l'API appartenenza esistente molto in passato e hanno esteso per memorizzare informazioni aggiuntive ecc Ma c'è tavoli quali

aspnet_Applications 
aspnet_Paths 
aspnet_SchemaVersions 
aspnet_WebEvent_Events 
aspnet_PersonalizationAllUsers 
aspnet_PersonalizationPerUser 

che sono estremamente ridondanti e non ho mai trovato l'uso per.

Modifica
Giusto per chiarire un paio di altri licenziamenti dopo la @ di drachenstern risposta, ci sono anche le colonne extra che ho alcuna utilità per nella tabella Membership/Utenti, ma che aggiungerebbe al carico utile di ogni select/inserire le dichiarazioni.

1. MobilePIN
2. PasswordQuestion/PasswordAnswer (Farò di recupero password a base di posta elettronica)
3. IsApproved (utente sarà sempre approvata)
4. commento
5. MobileAlias ​​
6. Nome utente/LoweredUsername (o Email/LoweredEmail) [email È lo username così ne ho solo bisogno 1]

Inoltre, ho sentito che i GUID non sono poi così veloci e preferirebbero invece avere numeri interi (come Facebook) che sarebbero anche esposti pubblicamente.

Come faccio a creare il mio provider di appartenenze, ri-utilizzando alcune delle API Membership (validazione, la crittografia delle password, login biscotto, ecc), ma solo con le tabelle che soddisfano le mie esigenze?

I collegamenti agli articoli e alle implementazioni esistenti sono i benvenuti, le mie ricerche su Google hanno restituito alcuni esempi di base.

Grazie in anticipo
Marko

Answer 1

@Marko Posso certamente capire che il sistema di appartenenza standard può contenere più funzionalità di quelle necessarie, ma la verità è che non ha alcuna importanza. Ci sono parti del sistema di appartenenza che non userete proprio come ci sono parti di .Net che non userete. Ci sono molte cose che .Net puoi fare che non utilizzerai mai, ma non passerai attraverso .Net e non comprenderesti questa funzionalità? Ovviamente no. Devi concentrarti sulle cose che sono importanti per ciò che stai cercando di realizzare e lavorare da lì. Non lasciarti coinvolgere nella paralisi dell'analisi. Sprecherai il tuo tempo, girerai le ruote e non finirai con qualcosa di meglio di ciò che è già stato creato per te. Ora a volte Microsoft sbaglia a volte, ma ottengono molte cose nel modo giusto. Non devi abbracciare tutto ciò che fanno per raggiungere i tuoi obiettivi - devi solo capire cosa è importante per le tue esigenze.

Come per i Guidi e int come chiavi primarie, lasciatemi spiegare qualcosa. Esiste una differenza cruciale tra una chiave primaria e un indice cluster. È possibile aggiungere una chiave primaria AND un indice cluster su colonne che non fanno parte della chiave primaria! Ciò significa che se è più importante disporre i dati in base a un nome (o altro), è possibile personalizzare l'indice cluster in modo da riflettere esattamente ciò di cui si ha bisogno senza influire sulla chiave primaria. Lasciatemelo dire in un altro modo: una chiave primaria e un indice cluster NON sono uno nella stessa. Ho scritto un post sul blog su come aggiungere un indice cluster e quindi una chiave primaria alle tue tabelle. L'indice cluster ordinerà fisicamente le righe della tabella nel modo in cui ne hai bisogno e la chiave primaria imporrà l'integrità di cui hai bisogno. Dai un'occhiata al mio post sul blog per vedere esattamente come puoi farlo.

Questo è il collegamento - http://iamdotnetcrazy.blogspot.com/2010/09/primary-keys-do-not-or-should-not-equal.html.

È davvero semplice, basta aggiungere l'indice cluster FIRST e quindi aggiungere la chiave primaria SECONDO. Deve essere fatto in questo ordine o non sarai in grado di farlo. Ciò presuppone, ovviamente, che si stia utilizzando SQL Server. La maggior parte delle persone non se ne rende conto perché SQL Server creerà un indice cluster sulla chiave primaria per impostazione predefinita, ma tutto ciò che devi fare è aggiungere prima l'indice cluster e poi aggiungere la chiave primaria e sarai pronto per andare. L'utilizzo di ints come chiave primaria può diventare MOLTO problematico in quanto il database e il sistema server si ridimensionano. Suggerirei di usare Guids e aggiungere l'indice cluster per riflettere il modo in cui effettivamente avete bisogno dei vostri dati memorizzati.

Ora, in sintesi, voglio solo dirti di creare qualcosa di eccezionale e non impantanarti con dettagli superficiali che non ti daranno abbastanza guadagni in termini di prestazioni. La vita è troppo breve. Inoltre, ricorda che il tuo sistema può essere veloce quanto il suo pezzo di codice più lento. Quindi assicurati di guardare le cose che effettivamente impiegano molto tempo e prenditi cura di loro.

E un'altra cosa aggiuntiva. Non puoi prendere tutto ciò che vedi sul web al valore nominale. La tecnologia cambia nel tempo. A volte potresti visualizzare una risposta a una domanda che qualcuno ha scritto molto tempo fa e che non è più rilevante oggi. Inoltre, le persone risponderanno alle domande e daranno informazioni senza aver effettivamente testato ciò che stanno dicendo per vedere se è vero o no. La cosa migliore che puoi fare per la tua applicazione è quella di sottoporlo a test molto bene. Se stai usando ASP.Net MVC puoi farlo nei tuoi test. Una cosa che puoi fare è aggiungere un ciclo for che aggiunge gli utenti alla tua app nel test e poi testare le cose. Questa è un'idea. Ci sono altri modi.Devi solo fare un piccolo sforzo per progettare bene i tuoi test o almeno abbastanza bene per i tuoi scopi.

Buona fortuna a te!

Answer 2

il provider di appartenenze corrente sembra un eccessivo BIG, c'è modo troppo funzionalità.

Tutto quello che voglio memorizzare è email/password e informazioni di base del profilo come First/LastName, numero di telefono. Avrò sempre e solo bisogno di 2 ruoli, gli amministratori & utenti.

Quindi utilizzare solo quella parte. Non userà le parti che non usi, e potresti scoprire che hai bisogno di quelle altre parti lungo la strada. Le classi sono già presenti nel framework .NET, quindi non devi fornire alcuna licenza o altro.

La dimensione del database è piuttosto piccola, e se si fa come faccio io, e si lascia aspnetdb su se stesso, allora non si prende nulla dagli altri database.

Avete un valido motivo per utilizzare un componente di terze parti? SOPRA cosa c'è già nel framework?

---

EDIT:

ci sono anche le colonne extra che ho ho alcuna utilità per nella tabella Membership/utenti, ma che aggiungerebbero al payload di ogni select/inserire le dichiarazioni.

MobilePIN PasswordQuestion/PasswordAnswer (vi fare il recupero della password a base di posta elettronica) IsApproved (utente sarà sempre approvato) commento MobileAlias ​​ username/LoweredUsername (o Email/LoweredEmail) [La posta elettronica è il nome utente ne servono solo 1)

Sembra che tu stia provando a microoptimize. Passare stringhe vuote è praticamente privo di costi (ok, è lì, ma devi profilare per sapere quanto ti costa, non sarà COSÌ tanto per utente). Anche noi normalmente non utilizziamo tutti questi campi nelle nostre app, ma usiamo il sistema di appartenenza senza alcun impatto negativo misurabile.

Inoltre, ho sentito che Guid's non è poi così veloce e preferirei avere numeri interi invece (come Facebook) che sarebbero anche esposti pubblicamente.

Ho sentito dire che al cookiemonster piacciono i biscotti. Di nuovo, senza profilazione, non sai se questo è dannoso. Di solito le persone usano i GUID perché vogliono che siano assolutamente (anche a un livello di assolutezza) unici, non importa quando è stato creato. Il costo di generarlo UNA VOLTA per utente non è poi così pesante. Non quando stai già creando un nuovo account.

---

Dal momento che sono assolutamente impostato sulla creazione di un MembershipProvider da zero, qui ci sono alcuni riferimenti:

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 entra nel dettaglio di questo nel suo libro ed è un buon riferimento per voi da avere così com'è.

Answer 3

La mia raccomandazione sarebbe per voi a benchmark. Aggiungi tutti i record che pensi di avere in produzione e invia un numero simile di richieste come faresti nella produzione e guarda come si comporta per il tuo ambiente.

La mia ipotesi è che sarebbe OK, l'overhead di cui si sta parlando sarebbe insignificante.