2012-04-10 24 views
6

Tengo una variable de sesión establecida en mi aplicación MVC. Siempre que esa sesión caduque y el usuario intente actualizar la página en la que se encuentra, la página emitirá un error porque la sesión ya no está establecida.MVC Equivalente a Page_Load

¿Hay algún lugar que pueda verificar para ver si la sesión está configurada antes de cargar una vista? Tal vez poniendo algo dentro del archivo Global.asax?

Podría hacer algo como esto al comienzo de CADA ActionResult.

public ActionResult ViewRecord() 
{ 
    if (MyClass.SessionName == null) 
    { 
     return View("Home"); 
    } 
    else 
    { 
     //do something with the session variable 
    } 
} 

¿Hay alguna alternativa para hacer esto? ¿Cuál sería la mejor práctica en este caso?

+1

Es necesario un filtro de acción personalizada, algo más de información http: // MSDN .microsoft.com/en-us/gg618482 –

+0

Discusiones similares aquí: http://forums.asp.net/t/1287687.aspx –

+0

Además del comentario de @ ChrisDiver, si lo necesita, se aplica a todos sus controladores/acciones , puede decorar un controlador base del que todos sus otros controladores heredan. – Chris

Respuesta

0

En primer lugar, debe redirigir a Inicio, no devolver la Vista de inicio, de lo contrario, tiene la extraña situación de que la página de inicio aparece a pesar de que la URL está en otro lugar.

En segundo lugar, la sesión nunca será nula, porque se crea una nueva sesión cuando la anterior expira o se restablece. En cambio, debería verificar su variable y si ESO es nulo, entonces sabrá que la sesión es nueva.

En tercer lugar, si su aplicación depende de los datos de esta sesión, entonces no usaría ninguna sesión. ¿Estás usando esto para almacenar datos en caché? Si es así, usar Caché puede ser una mejor opción (su aplicación recibe una notificación cuando caducan los elementos de caché).

Lamentablemente, este es probablemente un caso de The XY Problem. Tienes un problema y crees que Session soluciona tu problema, pero te encuentras con un problema diferente con Session, por lo que estás preguntando cómo resolver el problema de sesión en lugar de cómo resolver el problema que Session está tratando de resolver.

¿Cuál es el problema real que está tratando de resolver con esto?

EDIT:

Basado en su comentario a continuación, ¿por qué no se pasa el número de cliente en la url:

http://website/Controller/ViewRecord/3 

public ActionResult ViewRecord(int id) 
{ 
    // do whatever you need to do with the customer ID 
} 
+0

La aplicación web permite buscar un cliente. Seleccionamos un cliente basado en su número de identificación. Estoy estableciendo que el número de identificación tiene una sesión.Aquí es donde hago eso en: '\t \t CIF public static string \t \t { \t \t \t llegar \t \t \t { \t \t \t \t si (HttpContext.Current.Session [ "CIF"] == null) \t \t \t \t \t return ""; . \t \t \t \t otro \t \t \t \t \t retorno HttpContext.Current.Session [ "CIF"] ToString(); \t \t \t} \t \t \t conjunto {HttpContext.Current.Session [ "CIF"] = Valor; } \t \t} '- Luego en una vista, estoy llamando a MyClass.CIF para obtener el valor de la sesión. – Turp

+0

@Turp - ¿Por qué necesita agregar al cliente a la sesión? ¿Por qué no simplemente pasar el número de cliente en la URL? Entonces, el valor no se almacena en la sesión y desaparece cuando ya no lo necesita. –

+0

Realmente no tenemos un motivo real, excepto que así fue como se hizo antes que yo en la versión original de la aplicación web. ¿Te refieres a algo parecido a '/ Customer/Edit/1234'? Habíamos discutido que no se ve * tan bueno * como '/ CustomerProfile/Edit' y otra cosa que se planteó fue que simplemente no queríamos que nuestros usuarios reemplazaran el número actual con un número aleatorio para obtener otro de nuestros clientes BTY, esta es una aplicación web interna solamente. Donde te paras en esto? – Turp

3

Si está en un controlador, puede hacer esto:

protected override void OnActionExecuting(ActionExecutingContext filterContext) 
{ 
    base.OnActionExecuting(filterContext); 
    ... // do your magic 
} 

Se disparará antes de cualquier ejecución de la acción. No se puede devolver una vista desde allí, sin embargo, tendrá que volver a dirigir a cualquier cosa que devuelve resultado de la acción, por ejemplo:

filterContext.Result = new RedirectToRouteResult(new RouteValueDictionary { { "controller", "Shared" }, { "action", "Home" } }); 

Pero, obviamente, que debe redirigir a la acción en el controlador que no está afectada por la anulación, de lo contrario, tiene una redirección circular. :)