¿Puedo utilizar Entity Framework con membresía de ASP.NET?

Question

Estoy creando (en realidad, volviendo a crear) una aplicación que tiene usuarios existentes 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 Membresía en ASP.NET. Estoy pensando en varias maneras de hacer esto y me gustaría algún consejo. Hasta ahora he hecho una pequeña investigación sobre esta idea, tal vez ha sido respondida en otro lado. Entonces, aquí va un grupo de preguntas relacionadas.

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

2. Si paso a los usuarios al sistema de Membresía, para alinear sus ID de usuario con los datos de otras tablas, ¿debo crear otro conjunto de tablas para datos de usuario encima de las tablas aspnet_ * a la DotNetNuke?

3. Quiero evitar una situación en la que utilizo las funciones integradas de membresía solo para autenticación de usuario y cambiar al contexto EF cuando estoy trabajando con datos etiquetados por el usuario. Parece torpe retirar la información del usuario para enlazar a una columna en un GridView yendo a un usuario de Membresía para cada fila, pero tal vez eso es lo que se necesita. ¿Debo aspirar y replicar las clases de Membresía en EF para recuperar datos?

4. Estaba pensando en la posibilidad de implementar algún tipo de proveedor de EF para Membresía, sobre la idea de que tal vez el proveedor podría sentarse dentro del modelo de datos EF en general. ¿Esto es una locura? (Nunca he escrito mi propio proveedor antes)

No dude en decirme que no estoy haciendo 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 quiere/necesita.

Si las funciones que necesita no concuerdan completamente con la implementación incorporada de la membresía asp.net, puede simplemente transferir su propio proveedor. Si va a utilizar solo un par de funciones, deberá implementar solo un par de métodos (no es necesario que complete la implementación de todos los métodos). Si necesita más funciones de las que admite, puede ser que usar el proveedor de membresía se interponga en su camino.

Answer 2

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