¿Puedo usar Entity Framework con la membresía ASP.NET?

Question

Estoy creando (realmente, volviendo a crear) una aplicación que tiene un usuario existente y otros datos en las bases de datos de MS-Access. Los datos se moverán a SQL Server, y parte de eso implica la migración de usuarios. Quiero usar EF para hacer ORM, y estoy bastante seguro de que sé cuál será el modelo de datos en SQL Server. Soy nuevo en EF pero no en ASP.NET, y me gustaría aprovechar las características de Membership en ASP.NET. Estoy pensando en varias maneras de hacer esto y me gustaría un consejo. He hecho solo una pequeña investigación sobre esta idea hasta ahora, tal vez haya sido respondida en otra parte. Entonces, aquí va un grupo de preguntas relacionadas.

1. ¿EF puede trabajar directamente con la membresía de ASP.NET a través de alguna clase o espacio de nombres que no conozco?

2. Si hago la transición de los usuarios al sistema de Membresía, para alinear sus ID de usuario con los datos de otras tablas, ¿debería crear otro conjunto de tablas para los datos del usuario sobre las tablas aspnet_ * a la DotNetNuke?

3. Quiero evitar una situación en la que use las funciones integradas de Membresía solo para la autenticación del usuario y para cambiar al contexto EF cuando trabajo con datos etiquetados por el usuario. Parece torpe retirar información de usuario para enlazar a una columna en un GridView al ingresar a un usuario de Membresía en cada fila, pero ¿quizás eso es lo que se necesita? ¿Necesito asimilarlo y replicar las clases de Membresía en EF para fines de recuperación de datos?

4. Estaba pensando en tal vez implementar algún tipo de proveedor de EF para Membresía, con la idea de que tal vez el proveedor podría estar dentro del modelo general de datos de EF. Es esta loca charla? (Nunca he escrito mi propio proveedor antes)

No dude en decirme que no tengo ningún sentido.

Answer 1

¿Por qué no hacerlo al revés? Puede implementar su propio proveedor de membresía para asp.net, que usa el modelo que desea / necesita.

Si las funciones que necesita no coinciden completamente con la implementación de membresía de asp.net incorporada, solo puede usar su propio proveedor. Si va a utilizar solo un par de funciones, deberá implementar solo un par de métodos (no tiene que completar la implementación de todos los métodos). Si necesita más funciones de las que admite, el proveedor de membresía podría interponerse en su camino.

Answer 2

1. Lo hacemos, pero no asignamos las tablas de Membresía. No debe presumir el uso del proveedor de membresía de SQL.
2. Asignamos la identidad del usuario, no el ID de DB. Sutil, pero importante. Nuevamente, recuerde que hay otros proveedores de membresía (por ejemplo, autenticación de dominio).
3. ¿Puedes aclarar la pregunta? No tendrá que replicar toda la información de membresía en su modelo EF, pero necesitará una lista de identidades conocidas.
4. No, en absoluto loco, pero difícil y probablemente innecesario.