asp.net mvc - tutorial - Menú impulsado por la base de datos de aplicaciones web MVC por permisos de usuario
roles y permisos en asp.net mvc (2)
Vamos a portar una aplicación heredada de Windows a una gran aplicación web para un mercado vertical. Mirando a MVC. Cada implementación puede tener de 50 a 5000 usuarios. Mirando poner navegación en la página maestra. La aplicación contendrá de 200 a 300 elementos de menú, lo que resulta en más de 500 visitas. Queremos mostrar un menú de navegación recortado para cada usuario según sus permisos de aplicación. Un usuario puede ver solo 20 artículos, o todos disponibles.
La mayoría de las publicaciones que he visto sugieren pasar elementos de navegación a la Página maestra a través de viewdata, establecidos en una clase de controlador base. Entiendo esto.
Cada uno de los potencialmente de 10 a 1000 usuarios tendrá un conjunto diferente de permisos.
¿Alguien tiene alguna solución que evite golpear la base de datos para obtener los elementos de menú de los usuarios en cada solicitud de controlador heredada del controlador base?
¿Existe un esquema de almacenamiento en caché que funcione para cada usuario?
¿Se debe manejar la navegación en un marco (no es mi elección)?
¿Es solo un precio que pagaremos por este enfoque de navegación?
Gracias por cualquier entrada!
Algunas ideas:
1.) Puede hacer que su barra de navegación html provenga de una Html.RenderAction (MVC Futures) y usar el caché de salida en eso.
2.) Puede generar el html para la barra de navegación por usuario, luego guardarlo en la base de datos y regenerarlo si cambian sus permisos de usuario. Entonces, todo lo que tendría que hacer es extraer el html del DB en cada registro de usuarios.
Puede comenzar guardando en caché las consultas de linq, lo que sería una buena forma de abordar esto en el nivel DB.
Hacer esto en MVC usando un filtro de acción tampoco sería demasiado difícil.
Implementé algo así en PHP hace un año, pero la idea general es la misma. En primer lugar, deberá asignar a cada configuración de menú una identificación única. De esta forma, cuando el usuario A y el usuario X solicitan la misma configuración de menú, se resuelve en el mismo archivo de caché.
La primera vez que se debe cargar un menú para el usuario, se carga desde la base de datos y se pasa al usuario. Simultáneamente, se guarda en un archivo de caché con el ID único en su nombre. En solicitudes posteriores, el filtro de acción puede cargar los datos del archivo de caché si existe y omitir la base de datos.