ASP.NET construído em perfil de usuário vs.classes/tabelas de usuário de estilo antigo

Question

Estou procurando orientação sobre as melhores práticas em torno do uso do recurso Perfil no ASP.NET.

Como você decide o que deve ser mantido no perfil de usuário integrado ou se deve criar sua própria tabela de banco de dados e adicionar uma coluna para os campos desejados?Por exemplo, um usuário tem um CEP, devo salvar o CEP em minha própria tabela ou devo adicioná-lo ao perfil xml web.config e acessá-lo através do mecanismo ASP.NET do perfil do usuário?

Os prós/contras que consigo pensar agora são que, como não conheço muito bem o perfil (é um pouco complicado Matriz agora), provavelmente poderei fazer o que quiser se seguir a rota da tabela (por exemplo, SQL para obter todos os usuários no mesmo CEP do usuário atual).Não sei se posso fazer o mesmo se usar o perfil ASP.NET.

Answer 1

Eu criei apenas 2 aplicativos que usaram o provedor de perfil.Desde então tenho evitado usá-lo.Em ambos os aplicativos, usei-o para armazenar informações sobre o usuário, como nome da empresa, endereço e número de telefone.

Isso funcionou bem até que nosso cliente quisesse encontrar um usuário por um desses campos.A pesquisa envolveu um looping todo perfil dos usuários e comparação das informações com os critérios de pesquisa.À medida que a base de usuários crescia, o tempo de pesquisa tornou-se inaceitável para o nosso cliente.A única solução foi criar uma tabela para armazenar as informações dos usuários.A velocidade de pesquisa aumentou imensamente.

Eu recomendaria armazenar esse tipo de informação em uma tabela própria.

Answer 2

O perfil do usuário é uma estrutura limpa e agradável para personalização individual (AKA.Propriedades do perfil).(por exemplo.igoogle) O problema dele não é projetado para consulta e não é ideal para compartilhamento de dados para o usuário público. (Você ainda seria capaz de fazê -lo, com baixo desempenho)

portanto, se você deseja aprimorar a experiência personalizada do usuário, o perfil do usuário seria uma boa opção.caso contrário, usar sua própria classe e tabela seria uma solução muito melhor.

Answer 3

Na minha experiência, é melhor manter as informações do perfil no mínimo, colocando apenas o essencial que é diretamente necessário para a autenticação.Outras informações, como endereços, devem ser salvas em seu próprio banco de dados pela lógica de sua própria aplicação; essa abordagem é mais extensível e de fácil manutenção.

Answer 4

Acho que depende de quantos campos você precisa.Pelo que sei, os perfis são essencialmente uma sequência longa que é dividida nos tamanhos de campo determinados, o que significa que eles não são escalonados muito bem se você tiver muitos campos e usuários.

Por outro lado, eles são integrados, portanto é uma maneira fácil e padronizada, o que significa que não há uma grande curva de aprendizado e você também pode usá-los em aplicativos futuros sem precisar ajustá-los para uma nova estrutura de tabela.

Criar seu próprio item permite colocá-lo em um banco de dados devidamente normalizado, o que melhora drasticamente o desempenho, mas você mesmo precisa escrever praticamente todo o código de gerenciamento de perfil.

Editar:Além disso, os perfis não são armazenados em cache, portanto, todo acesso a um perfil vai primeiro para o banco de dados (ele é então armazenado em cache para essa solicitação, mas a próxima solicitação irá obtê-lo do banco de dados novamente)

Se você está pensando em escrever seu próprio trabalho, talvez um Provedor de perfil personalizado oferece o melhor dos dois mundos - integração perfeita, mas com as coisas personalizadas que você deseja fazer.

Answer 5

Acho que é melhor usá-lo para dados suplementares que não são críticos para o usuário e que normalmente só são importantes quando o usuário está efetuando login de qualquer maneira.Pense em dados que não quebrariam nada importante se fossem todos apagados.

é claro que isso é preferência pessoal, mas outros levantaram outras questões importantes.

Também é muito útil considerando que pode ser usado para um usuário não autenticado cujo perfil é mantido com um cookie anônimo.