¿Dónde puedo almacenar detalles de usuario adicionales utilizando ASP.NET MVC y SqlMembershipProvider?

Question

Por lo tanto, estoy creando un sitio web ASP.NET MVC.

Tiene una página de registro de usuarios bastante compleja con muchos campos. Mi pregunta es, ¿dónde debería persistir esto? Las tablas de usuarios creadas por la herramienta de membresía-proveedor no contienen estas columnas y me confunden las mejores prácticas en términos de almacenar esta información adicional sobre cada usuario.

¿Es aquí donde entra en juego un proveedor de perfiles? ¿Cómo trabajan? Si no es así, ¿de qué otra manera persiste y almacena los detalles de usuario adicionales que no se proporcionan en las columnas de stock de las tablas MembershipProvider?

Puede alguien me punto a algunos recursos sobre cómo se maneja esto, cómo acceder a los datos de usuario adicionales cuando los necesito, cómo crear un nuevo usuario con toda esta información, etc.

Answer 1

Este article de CODE Magazine ayudaron yo con este problema.

Answer 2

Aquí es donde entra el proveedor de perfiles ASP.NET. Puede usarlo para almacenar la información de perfil que desee sobre un usuario. Todo lo que necesita hacer es agregar los campos que necesita en el archivo web.config, MSDN Link on how to configure the profile fields in web.config file. Para resumir el artículo, solo debe agregar el nombre y los valores de tipo que desea almacenar en el nodo de propiedades del elemento de perfil. He aquí un ejemplo:

<profile enabled="true"> 
    <properties> 
    <add name="Name" /> 
    <group name="Address"> 
     <add name="Street" /> 
     <add name="City" /> 
     <add name="Zip" type="System.Int32" /> 
    </group> 
    </properties> 
</profile> 

En ASP.NET formularios web, Visual Studio crea una clase automagicamente perfil fuertemente tipado que hará referencia a las propiedades de su perfil personalizado. En MVC, esto no sucede. Para hacer referencia a la información de perfil de un usuario, simplemente llame a HttpContext.Profile ["PropertyName"]. Un ejemplo:

HttpContext.Profile["Name"] = name; 
HttpContext.Profile.GetProfileGroup("Address")["Zip"] = zip; 

Editar: Como se señaló Andy, utilizando el SqlProfileProvider por defecto no es muy buena si quieres ejecutar consultas sobre estas propiedades. Él tiene toda la razón, y tal vez debería haber notado originalmente esta limitación. Esta limitación existe porque SqlProfileProvider almacena todos los datos de perfil en tres columnas: PropertyNames y PropertyValuesString/PropertyValuesBinary. Todas las claves se almacenan en el campo de PropertyNames, los valores que se pueden almacenar como una cadena se almacenan en el campo PropertyValuesString, etc. Esto significa que es extremadamente difícil hacer una consulta como "Seleccionar * de aspnet_Profile donde Age> 10".

Answer 3

No estoy muy seguro de que exista una mejor práctica y realmente depende de cómo quiera usar la información.

Primero, debe reconocer que la membresía y los perfiles son dos cosas separadas. La funcionalidad de membresía, perfil y rol de ASP.NET está diseñada para ser utilizada como un servicio que sirve a múltiples sitios/aplicaciones.

Si observa el esquema de estas relaciones, notará que los usuarios son únicos en el sistema pero que un usuario puede compartirse entre aplicaciones. Eso significa que su información de perfil también se comparte entre las aplicaciones. La membresía es en realidad la asociación de un usuario a una aplicación y contiene información sobre su relación con esa aplicación específica (contraseña, contraseña Q & A, etc.).

Puede utilizar el proveedor de perfiles como Ryan sugirió, pero 1) esa información no se consulta fácilmente si desea recopilar métricas de perfil y 2) se comparte entre todos los consumidores de los servicios de membresía/perfil. Sin embargo, puede ampliarlo para satisfacer sus necesidades.

Puede ampliar el proveedor de membresía como sugirió Gortok y esa información sería relativa a la aplicación, pero debe asegurarse de no romper los consumidores existentes del servicio modificando los procedimientos almacenados existentes o las tablas de manera que cambia su interfaz o intención.

La otra opción es que puede tratarlo como un servicio y realizar un seguimiento de esta información por su cuenta, haciendo referencia a su propia implementación de perfil utilizando la identificación de usuario del proveedor asp.net sql.

Hay una buena serie (16 partes) en Membership, Profiles, and Roles en 4 chicos de Rolla que recomiendo leer y luego, una vez que esté familiarizado con todas las piezas móviles, tome una decisión educada sobre dónde es mejor almacenar y la mejor forma de estructurar la información de perfil que desea crear.

Answer 4

Sé que esta publicación se ha publicado durante mucho tiempo, y el contexto de la pregunta probablemente fue para mvc2 o anterior.

Ahora es mvc3, y pensé que tal vez otros que buscan respuestas para el contexto mvc5 podrían estar interesados ​​en esta solución.

En un proyecto mvc5 estándar que tiene cuenta de usuario individual habilitado el Encontrará el siguiente bloque de código listo para su uso en el proyecto {} /Models/IdentityModel.cs

// You can add profile data for the user by adding more properties to your ApplicationUser class, please visit http://go.microsoft.com/fwlink/?LinkID=317594 to learn more. 
public class ApplicationUser : IdentityUser 
{ 
} 

sólo tiene que añadir más propiedades en este la clase y las propiedades se conservarán en la base de datos , por ejemplo.

public class ApplicationUser : IdentityUser 
{ 
     public string FirstName { get; set; } 
     public string LastName { get; set; } 
     public string Email { get; set; } 
     public bool Active { get; set; } 
     public DateTime DateRegistered { get; set; } 
}