¿Cómo usaría Entity Framework (1.0) con membresía ASP.Net?

Question

Estoy tratando de diseñar un modelo de entidad para una aplicación que use membresía ASP.Net para su autenticación de usuario. En la mayoría de los esquemas de base de datos que creo, los registros generalmente terminan relacionados con los usuarios a través del campo UserId en la tabla aspnet_users. Eso funcionó bien para mí en el pasado, pero ahora que estoy usando EF, tengo algunos problemas conceptuales para descubrir cómo voy a hacer referencia al usuario de una entidad.

Por ejemplo, supongamos que tenemos una entidad de "publicación" que contiene una propiedad "postedBy". ME GUSTARÍA poder obtener el nombre de usuario del usuario que creó esta publicación con algo como post.user.username, pero soy cauteloso de crear una entidad basada en la tabla aspnet_user por temor a crear un modelo que permita omito la clase de Membresía cuando hago cambios a la base de datos.

He considerado simplemente dejar el campo post.userId como guid y luego exigir que cualquier código que necesite saber el nombre de usuario use ese guid para obtener el usuario de la clase Membership, pero eso parece "inelegible".

¿Alguien tiene alguna recomendación para los diseños de modelo de entidad que se integran con la Membresía? Sería razonable que suceda con una entidad de usuario de "solo lectura".

Answer 1

Mi consejo es: "Do not."

Déjame ser más específico.

Al utilizar el ID de usuario como clave externa asignada vincula su modelo de entidad no a la membresía ASP.NET en general, sino al Proveedor de membresía SQL en general. ¿Qué sucede si luego quieres usar la autenticación de dominio o OpenID?

No me malinterpreten: el 99.9% de las veces es correcto vincular las referencias de DB junto con una clave externa. Diablos, incluso podrías hacerlo aquí, pero no lo mapees en tu modelo de entidad. Debe mantener un muro de separación lógica entre los proveedores de membresía y sus propios datos. Accedes a tus datos a través de EF. Accedes a los datos de membresía mediante la API de membresía. El hecho de que vivan en la misma base de datos porque está utilizando el proveedor de membresía de SQL es un detalle de la implementación.

Actualización: He ampliado esta idea en a blog post.