.NET Membership com Pattern Repository

Question

A minha equipa está no processo de concepção de um modelo de domínio que irá esconder várias fontes de dados diferentes por trás de uma abstração repositório unificado. Um dos principais drivers para esta abordagem é a probabilidade muito alta de que essas fontes de dados passará por mudanças significativas no futuro próximo e não quer ser re-escrever a lógica do negócio quando isso acontece. Uma fonte de dados será nosso banco de dados de adesão que foi originalmente implementado usando o padrão Provider ASP.Net Membership. O provedor de associação está ligada ao espaço de nomes System.Web.Security mas temos uma diretriz de design exigindo que a nossa camada de modelo de domínio não é dependente System.Web (ou qualquer implementação other / ambiente de dependência), uma vez que será consumida em ambientes diferentes - nem queremos nossos websites comunicando diretamente com bancos de dados.

Estou pensando o que seria uma boa abordagem para conciliar a abordagem MembershipProvider com nossa arquitetura n-tier abstraída. Meu sentimento inicial é que poderíamos criar um "DomainMembershipProvider" que interage com o modelo de domínio e, em seguida, implementar objetos no modelo que lidam com a lógica de validação repositório e alça / negócio. O repositório, então, implementar o acesso a dados usando o nosso (ainda não definido) ferramenta de acesso ORM / dados.

Existem algumas buracos gritantes esta abordagem - Eu não tenho trabalhado em estreita colaboração com a classe MembershipProvider assim pode muito bem estar faltando alguma coisa. Como alternativa, há uma abordagem que você acha que vai servir melhor os requisitos que eu descrevi acima?

Agradecemos antecipadamente por seus pensamentos e conselhos.

Saudações, Zac

Answer 1

Tem sido 6 meses desde que a pergunta foi feita e ninguém parece ter sido capaz de dar uma resposta assim que eu pensei que eu ia explicar a solução que finalmente escolheu.

Basicamente, nós decidimos não utilizar qualquer implementação do MembershipProvider - em vez usamos nosso próprio costume Membership Serviço sentado em cima de um repositório. Era importante para nós manter o banco de dados aspnet_Membership existente para o nosso repositório tem, basicamente, duplicado o built-in funcionalidade SqlMembershipProvider (pelo menos, os aspectos que precisamos dela) - inicialmente via Linq-to-SQL mas agora estamos em transição para NHibernate . O plano é substituir o banco de dados de membros em um ano ou assim, quando todos os nossos sites são atualizados para usar o novo modelo.

Foi possível usar um provedor de associação personalizado, mas no final ficou claro que era mais simples, mais consistente e mais sustentável de usar uma implementação personalizada. Nós ainda estamos usando o built-in funcionalidade de autenticação de formulários para verificar se um usuário está conectado e para redirecionar os usuários que tentam acessar áreas seguras de nosso site sem primeiro ser autenticado - mas temos substituído a funcionalidade que está ligada ao provedor de perfil .

Em última análise, os nossos sentimentos sobre este são de que, enquanto o provedor de associação é uma ferramenta poderosa e fácil de usar dentro de ASP.Net, se ele não se encaixa com a abordagem mais ampla usado em seu aplicativo, vale a pena considerar uma abordagem alternativa.

Answer 2

Interessante, obrigado por publicar a sua solução final. Estou em uma situação semelhante, mas escrever um MembershipProvider personalizado. Eu não sei onde colocar o provedor porque ele precisa de acesso ao DB, bem como System.Web namespace. Parece que é a única classe que viola toda esta separação de interesses design.