Los roles funcionan asignando un valor a algo que un usuario puede hacer. Los Roles no cambian, pero el comportamiento de esos roles sí lo hace. Las soluciones ultra dinámicas tienden a ser excesivas.
Así que tal vez tienen las siguientes funciones
- superadministrador
- Soporte
- administración
Puede tener diferentes acciones (esto dependerá de su sistema)
Etc
- Superadministrador [Ver, editar, aprobar]
- Soporte [Ver]
- administración [Ver, Editar]
La parte dinámica viene en la asignación de Acciones. Al hacer las cosas de esta manera, no te importa en qué personaje esté, sino qué acciones tienen. Las acciones son el aspecto dinámico en esta relación. Cuando se realiza una solicitud que va a utilizar el papel usuarios a buscar las acciones asignadas a ese papel (Base de datos manejada para hacer modificable)
la incorporación de este en su estructura de base de datos como "papel tiene muchas acciones", significa que si las cosas cambian en el futuro, deberá actualizar la relación en la base de datos, pero no el código.
Una estructura de base de datos podría ser algo como esto, depende de sus necesidades.
- UserRole [ID, nombre de usuario RoleID] (Si el usuario se asigna más de un rol que heredan todas las acciones, que podrían ser duplicados y por lo tanto seleccionarse distintos o evitar esta situación, pero creo que el primero proporciona una mayor flexibilidad sin complejidad y limitación. NOTA: la tabla UserRole podría desnormalizarse aún más para hacer que UserNames sea único.)
- papel [ID, Nombre]
- Acción [ID, Nombre]
- RoleAction [ID, RoleID, ActionID] (Clave única restricción sobre RoleID y ActionID)
Cuando se hace una solicitud , se identifica al usuario, etc Nombre de usuario, Luego del entrenamiento, que Rol (s) que están en quering por la RoleAction y por lo tanto su carga asociada acciones
que usarían enumeraciones para sus valores de acción y de rol. Esto hace que sea más fácil trabajar con. Para asegurarse de que la Base de datos y el Código están en el receptor, asegúrese de escribir una Prueba de unidad para conciliar los valores de la base de datos con los valores enum.
Creo que sin el uso de constantes como las otras respuestas han sugerido, entonces esto aún requeriría una codificación rigurosa de los roles en el código. –
Sería sí, pero el uso de roles como se ilustra en la pregunta no se entiende bien y, por lo tanto, el deseo de extender los roles en algo dinámico, cuando en realidad es su comportamiento que es dinámico. – Jonathan
Muchas gracias por esta respuesta. Es realmente útil ya que estaba habilitando/deshabilitando usuarios en cada parte donde necesitaba hacer una acción en lugar de preguntar a la base de datos si podían o no. Sin embargo, todavía me pregunto qué sucede si un usuario en particular puede crear ciertos registros, pero no todos: la creación de una acción llamada "crear" no sería la solución más eficiente, ¿verdad? ¿Tendré que crear relaciones entre las acciones de la tabla y el resto de las tablas? ¡Muchas gracias por tu ayuda! – aleafonso