MembershipProvider personalizado com a interface Web e DAL

Question

Eu estou trabalhando em uma solução ASP.NET com 2 projetos. Uma delas é a interface web e o outro contém a minha lógica de negócios. Eu estou usando LINQ to SQL para o meu acesso a dados no segundo projeto.

Além de meu banco de dados, eu tenho uma tabela chamada usuários que detém as informações do usuário.

Eu comecei a implementar um MembershipProvider. Eu noto que MembershipUser é acoplado com MembershipProvider. Qual é a maneira mais correta de obter o meu BLL / DAL para falar sobre usuários? Devo minimamente implementar MembershipUser e sempre que um usuário chama um método, ele irá chamar para, por exemplo. GetUserInfo () no meu BLL / DAL, para obter informações completas sobre o usuário?

Ou devo fazer os métodos de classe MembershipUser chamar meu costume "Usuários" métodos de classe (como um invólucro) na BLL / DAL (esta classe usuários personalizados não está relacionado com o LINQ)?

Ou eu posso de alguma forma estender o LINQ to SQL classe "CFUsers" para estender MembershipUser.

Espero que este sentimento marcas.

Answer 1

Eu costumo ver este um entidades separadas como gira MembershipUser ao redor de adesão que é uma preocupação genérica e um usuário em sua gira sistema em torno de tudo o que os seus vínculos de domínio, eu vejo o seu ponto de vista em que estas duas entidades poderia ser contida em um, tão. Profiles é definitivamente a maneira mais fácil de ir.

Há uma walkthough sobre a documentação do MSDN em http://msdn2.microsoft.com /en-us/lib...US,VS.80).aspx e um boa explicação passo a passo de Scott Guthrie em http://weblogs.asp.net/scottgu/archi. ..18 / 427754.aspx

Como sempre Depende de quais são seus objetivos. Somando-se Profile é um mecanismo simples para dados adicionais. Ela exige muito pouco em termos de personalização e torna a informação facilmente disponível para a aplicação web. Isto pode não ser onde você deseja armazenar esse tipo de dados; se não, é uma não-solução.

Se isto não se encaixa, fazendo um novo provedor derivado do padrão (para herdar o que você já tem) é uma ótima opção. e, claro, o http: // codesmart.wordpress.com/2009/03/27/extending-the-microsoft-aspnet-membership-provider/