ASP.NET incorporato nel profilo utente rispetto alla vecchia classe utente/tabelle

Question

Sto cercando indicazioni in merito alla procedura migliore per l'utilizzo della funzionalità Profilo in ASP.NET.

Come si decide cosa mantenere nel profilo utente incorporato, oppure se si deve creare la propria tabella di database e aggiungere una colonna per i campi desiderati? Ad esempio, un utente ha un codice di avviamento postale, dovrei salvare il codice di avviamento postale nella mia stessa tabella, o dovrei aggiungerlo al profilo xml web.config e accedervi tramite il meccanismo ASP.NET del profilo utente?

I pro/contro mi viene in mente in questo momento sono che, dal momento che non conosco il profilo molto bene (è un po 'un Matrix in questo momento), probabilmente posso fare quello che voglio, se vado il percorso della tabella (ad esempio, SQL per ottenere tutti gli utenti nello stesso codice postale dell'utente corrente). Non so se posso fare lo stesso se utilizzo il profilo ASP.NET.

Answer 1

Ive ha creato solo 2 applicazioni che utilizzavano il provider del profilo. Da allora sono rimasto lontano dall'usarlo. Per entrambe le app l'ho usato per memorizzare informazioni sull'utente, come il nome della società, l'indirizzo e il numero di telefono.

Questo ha funzionato fino a quando il nostro cliente voleva essere in grado di trovare un utente da uno di questi campi. Ricerca in corso tramite looping ogni profilo utente e confronto delle informazioni con i criteri di ricerca. Con l'aumentare della base di utenti, il tempo di ricerca è diventato inaccettabile per il nostro cliente. L'unica soluzione era creare una tabella per archiviare le informazioni degli utenti. La velocità di ricerca è stata aumentata immensamente.

Si consiglia di memorizzare questo tipo di informazioni nella propria tabella.

Answer 2

Nella mia esperienza è meglio mantenere le informazioni nel profilo al minimo, inserire solo gli elementi essenziali che sono direttamente necessari per l'autenticazione. Altre informazioni come gli indirizzi dovrebbero essere salvate nel proprio database secondo la propria logica applicativa, questo approccio è più estensibile e mantenibile.

Answer 3

Penso che dipenda da quanti campi sono necessari. A mia conoscenza, i Profili sono essenzialmente una lunga stringa che viene divisa in base alle dimensioni del campo date, il che significa che non si adattano molto bene se si hanno molti campi e utenti.

D'altra parte, sono integrati, quindi è un modo semplice e standardizzato, il che significa che non c'è una grande curva di apprendimento e che è possibile utilizzarlo anche in future app senza doverle modificare in una nuova tabella struttura.

Rolling your own thing consente di inserirlo in un database correttamente normalizzato, che migliora drasticamente le prestazioni, ma è necessario scrivere praticamente tutto il codice di gestione del profilo.

Edit: Inoltre, i profili non vengono memorizzati nella cache, in modo ogni accesso a un profilo va al database prima (è poi memorizzato nella cache per tale richiesta, ma la richiesta successiva otterrà dal database di nuovo)

Se Stai pensando di scrivere le tue cose, forse un custom Profile Provider ti dà il meglio di entrambi i mondi: integrazione perfetta, eppure le cose personalizzate che vuoi fare.

Answer 4

profilo utente è un quadro pulito e piacevole per la personalizzazione individuale (AKA. Proprietà profilo). (ad esempio iGoogle) il problema è che non è progettato per la query e non è l'ideale per la condivisione dei dati all'utente pubblico.(Sarai comunque in grado di farlo, a basse prestazioni)

quindi, se vuoi migliorare l'esperienza utente personalizzata, il profilo utente sarebbe un buon modo per andare. altrimenti, usare la propria classe e la propria tabella sarebbe una soluzione molto migliore.

Answer 5

Penso che sia preferibile utilizzarlo per dati supplementari che non sono fondamentali per l'utente che è normalmente importante solo quando l'utente sta effettuando l'accesso in ogni caso. Pensa a dati che non romperebbero nulla di importante se fossero stati tutti cancellati.

ovviamente questa preferenza personale, ma altri hanno sollevato alcune altre questioni importanti.

Molto utile anche considerando che può essere utilizzato per un utente non autenticato il cui profilo è gestito con un cookie anonimo.