2010-04-27 5 views
5

Tengo una vista para mostrar una lista de elementos. El usuario puede editar, eliminar o crear nuevos elementos, pero de acuerdo con sus autorizaciones, pueden o no tener permiso para realizar algunas de estas acciones.¿Cómo mantener las vistas libres de lógica de autorización en mvc?

que tienen la obligación de mostrar sólo las acciones que se le permite hacer el usuario actual, pero no quiero saturar los puntos de vista con la autorización si-else de

Desdeñe de ser un requisito muy común, lo no puede encontrar una manera realmente satisfactoria de hacerlo.

Mi mejor enfoque hasta ahora es proporcionar una sobrecarga al método de extensión Html.ActionLink que toma el permiso para solicitar, pero habrá escenarios más complejos, como ocultar bloques enteros de html o cambiar un cuadro de texto por una etiqueta + oculto

¿Hay una mejor manera de hacerlo?

Respuesta

2

Un ejemplo que puedo pensar sería invocar a Html.RenderAction (enlace: http://msdn.microsoft.com/en-us/library/ee703490.aspx), y luego pasar el enlace que desea usar como valor de ruta al método de acción (aparecerá como un parámetro en su acción) Debido a que es una RenderAction, puede volver al proceso del controlador y así puede hacer que represente la vista o los datos que desee dependiendo del estado del usuario.

Ejemplo:

<% Html.RenderAction("Permissions" /* Controller */, "PermissionLink", new { Url = "Admin.aspx" }); %> 

Y el controlador podría tener algo como:

public ActionResult PermissionsLink (string url) 
{ 
    // Do Whatever kind of Authentication you want here, Session is available, etc 

    if(authenticated) 
     return View("Link"); 
    else 
     return View("Blank"); 
} 
+0

Esta es una mejor manera de hacer lo que Krisg propone en su respuesta, pero sigue siendo a nivel de componente (krisg estaba a nivel de vista). Quizás no estoy lo suficientemente loco como para hacer un componente "RowAction" y llamarlo en cada fila para representar las acciones que el usuario puede hacer, pero es posible que finalmente implemente un enfoque de casilla de verificación con solo una barra de herramientas para actuar sobre los elementos . Me llevó un tiempo, pero lo entendí. Tnks. –

0

Tuvimos este mismo problema. Terminamos escribiendo muchos métodos de ayuda y en los casos en que se requería mucha salida html, los pusimos en vistas parciales.

0

¿No sería más sencillo para crear varios puntos de vista con los diferentes controles en base a lo que valora el usuario puede cambiar, a continuación, devolver la vista correcta en función de los derechos de acceso del usuario?

Las vistas deben ser solo para presentar información, realmente no debe haber ninguna lógica condicional contenida en ellas, o al menos un mínimo.

Siempre he encontrado que cuando llego al punto en el que me cuesta asimilar una situación como la tuya, la mejor solución es volver al controlador y evaluar electrónicamente a qué estoy pasando. la vista en primer lugar.

Para cuando se llame a View para hacer su trabajo, todas las "decisiones" importantes ya deberían haberse realizado.

+2

Entiendo lo que dices, pero tener una opinión para cada decisión que se tome no es pragmático. Solo en mi ejemplo anterior habría 7 vistas (una para cada combinación). Ahora piense en una aplicación comercial con muchas funciones de acceso restringido a un alto nivel de detalle. A veces, la composición es el mejor enfoque, pero aún así, hay decisiones que deben tomarse en el nivel de los componentes. –

+0

Al hacerlo, conté 34 vistas para mi acción de proceso de proceso. Este no es un buen enfoque. :/ – dariol

0

En situaciones complicadas donde muchas condiciones y reglas que estoy haciendo esto de esa manera:

modelo de vista

public class ModelView 
{ 
    private IAuthorisationService { get; set; } 

    public bool CanShow 
    { 
     ... 
    } 
} 

Vista:

<% if(Model.CanShow) { %> 
    <html> 
<% } %> 
+0

Esto es lo que no quiero hacer: poner declaraciones if en la vista para autorización. Esto es aún mejor que cargar permisos en ViewMessage o algo así y luego consultarlo. –

0

Yo personalmente no veo nada malo con este tipo de lógica condicional dentro de la vista. La lógica sigue siendo la presentación. Usted decide si mostrar u ocultar, activar o desactivar, resaltar, etc. Este es el trabajo de la vista, no del controlador. Siempre que la vista no necesite calcular nada para tomar su decisión.El controlador debe ser independiente de la implementación de la vista tanto como al revés.

Mi enfoque sería la siguiente:

  • Hacer el controlador hacer la lógica real de decidir el nivel de acceso que el usuario tiene
  • pasar esta información a la vista utilizando (es decir, a través del modelo de vista), pero de una manera que es neutral para los detalles de implementación (es decir, "el usuario es administrador", "el usuario es autor", etc.)
  • Deje que la vista se dibuje adecuadamente utilizando solo los datos precompilados que proporciona el controlador.

Esto también tiene la ventaja de que la vista en sí misma se puede quitar y reemplazar sin ningún efecto en el controlador.

Cuestiones relacionadas