Membresía .NET con patrón de repositorio

Question

Mi equipo está en el proceso de diseñar un modelo de dominio que ocultará varias fuentes de datos diferentes detrás de una abstracción de repositorio unificada. Uno de los principales impulsores de este enfoque es la alta probabilidad de que estas fuentes de datos experimenten cambios significativos en el futuro cercano y no queremos volver a escribir la lógica empresarial cuando esto suceda. Una fuente de datos será nuestra base de datos de membresía, que se implementó originalmente utilizando el proveedor de membresía ASP.Net predeterminado. El proveedor de membresía está vinculado al espacio de nombres System.Web.Security, pero tenemos una guía de diseño que requiere que nuestra capa de modelo de dominio no dependa de System.Web (o cualquier otra implementación / dependencia del entorno) ya que se consumirá en diferentes entornos: ni queremos que nuestros sitios web se comuniquen directamente con las bases de datos.

Estoy considerando cuál sería un buen enfoque para conciliar el enfoque MembershipProvider con nuestra arquitectura abstracta de n niveles. Mi sensación inicial es que podríamos crear un " DomainMembershipProvider " que interactúa con el modelo de dominio y luego implementa objetos en el modelo que se ocupan del repositorio y manejan la validación / lógica empresarial. El repositorio luego implementaría el acceso a los datos utilizando nuestra herramienta de acceso a datos / ORM (aún no decidida).

¿Hay algún agujero evidente en este enfoque? No he trabajado estrechamente con la clase MembershipProvider, por lo que es posible que me falte algo. Alternativamente, ¿existe un enfoque que cree que cumplirá mejor los requisitos que describí anteriormente?

Gracias de antemano por sus pensamientos y consejos.

Saludos, Zac

Answer 1

Han pasado 6 meses desde que se hizo la pregunta y nadie parece haber podido dar una respuesta, así que pensé en explicar la solución que finalmente elegimos.

Básicamente, hemos decidido no utilizar ninguna implementación del MembershipProvider; en su lugar, utilizamos nuestro propio Servicio de Membresía personalizado sentado encima de un repositorio. Era importante para nosotros mantener la base de datos aspnet_Membership existente, por lo que nuestro repositorio básicamente ha duplicado la funcionalidad incorporada de SQLMembershipProvider (al menos, los aspectos que necesitamos), inicialmente a través de Linq-to-SQL, pero ahora estamos haciendo la transición a NHibernate . El plan es reemplazar la base de datos de membresía en aproximadamente un año cuando todos nuestros sitios web se actualicen para usar el nuevo modelo.

Era posible usar un proveedor de membresía personalizado, pero al final se hizo evidente que era más simple, más consistente y más fácil de usar una implementación personalizada. Todavía estamos utilizando la funcionalidad de autenticación de formularios incorporada para verificar que un usuario ha iniciado sesión y para redirigir a los usuarios que intentan acceder a áreas seguras de nuestro sitio sin primero autenticarse, pero hemos anulado la funcionalidad que está vinculada al proveedor del perfil. .

En última instancia, nuestra opinión al respecto es que, si bien el proveedor de membresía es una herramienta poderosa y fácil de usar dentro de ASP.Net, si no se ajusta al enfoque más amplio utilizado en su aplicación, vale la pena considerar un enfoque alternativo.

Answer 2

Interesante, gracias por publicar su solución final. Estoy en una situación similar, pero escribiendo un proveedor de membresía personalizado. No sé dónde colocar al proveedor porque necesita acceso a la base de datos, así como al espacio de nombres System.Web. Parece que es la única clase que viola todo este diseño de separación de preocupaciones.