ASP.NET incorporado en el perfil de usuario vs. antigua clase de usuario/tablas
profile (5)
Creo que eso depende de cuántos campos necesites. Que yo sepa, los perfiles son esencialmente una cadena larga que se divide en los tamaños de campo dados, lo que significa que no se escalan muy bien si tiene muchos campos y usuarios.
Por otro lado, están integrados, por lo que es una forma sencilla y estandarizada, lo que significa que no hay una gran curva de aprendizaje y que puede usarla también en aplicaciones futuras sin necesidad de ajustarla a una nueva estructura de tabla.
Hacerlo por sí mismo le permite colocarlo en una base de datos correctamente normalizada, lo que mejora drásticamente el rendimiento, pero tiene que escribir prácticamente todo el código de administración del perfil.
Editar: Además, los perfiles no están en la memoria caché, por lo que cada acceso a un perfil va primero a la base de datos (luego se almacena en caché para esa solicitud, pero la próxima solicitud la obtendrá de la base de datos nuevamente)
Si está pensando en escribir sus propias cosas, tal vez un proveedor de perfiles personalizado le brinde lo mejor de ambos mundos: integración perfecta, pero las cosas personalizadas que desea hacer.
Estoy buscando orientación con respecto a las mejores prácticas en torno al uso de la función Perfil en ASP.NET.
¿Cómo se decide qué se debe guardar en el perfil de usuario incorporado, o si debe crear su propia tabla de BD y agregar una columna para los campos deseados? Por ejemplo, un usuario tiene un código postal, ¿debo guardar el código postal en mi propia tabla o debo agregarlo al perfil web.config xml y acceder a él a través del perfil de usuario ASP.NET mechanize?
Los pros / contras en los que puedo pensar es que, dado que no conozco muy bien el perfil (en este momento es un poco Matrix ), probablemente pueda hacer lo que quiera si voy por la ruta de la tabla (por ejemplo, SQL a obtener todos los usuarios en el mismo código postal que el usuario actual); No sé si puedo hacer lo mismo si uso el perfil de ASP.NET.
En mi experiencia, lo mejor es mantener la información en el perfil al mínimo, solo poner los elementos esenciales que se necesitan directamente para la autenticación. Otra información, como las direcciones, debe guardarse en su propia base de datos con su propia lógica de aplicación, este enfoque es más extensible y mantenible.
Solo he creado 2 aplicaciones que utilizan el proveedor de perfiles. Desde entonces me he mantenido alejado de usarlo. Para ambas aplicaciones, lo utilicé para almacenar información sobre el usuario, como el nombre de la empresa, la dirección y el número de teléfono.
Esto funcionó bien hasta que nuestro cliente quería poder encontrar un usuario por uno de estos campos. La búsqueda implicó un bucle a través de cada perfil de usuario y la comparación de la información con los criterios de búsqueda. A medida que creció la base de usuarios, el tiempo de búsqueda se volvió inaceptable para nuestro cliente. La única solución fue crear una tabla para almacenar la información de los usuarios. La velocidad de búsqueda se incrementó inmensamente.
Yo recomendaría almacenar este tipo de información en su propia tabla.
El perfil de usuario es un marco agradable y limpio para la personalización individual (como las Propiedades del Perfil). (por ejemplo, iGoogle), el problema es que no está diseñado para consultas y no es ideal para el intercambio de datos a usuarios públicos. (aún así podrías hacerlo, con bajo rendimiento)
por lo tanto, si desea mejorar la experiencia de usuario personalizada, el perfil del usuario sería una buena forma de hacerlo. de lo contrario, use su propia clase y la tabla sería una solución mucho mejor.
Creo que es mejor usarlo para datos complementarios que no son críticos para el usuario y que normalmente solo son importantes cuando el usuario inicia sesión de todos modos. Piensa en datos que no rompan nada importante si todo se borró.
por supuesto, esa es la preferencia personal, pero otros han planteado algunos otros temas importantes.
También es muy útil teniendo en cuenta que se puede utilizar para un usuario no autenticado cuyo perfil se mantiene con una cookie anónima.