2009-05-03 12 views
6

Me gustaría escuchar sus opiniones y tal vez mejores sugerencias para el siguiente escenario:ASP.NET MVC, ActionFilters, clases estáticas y los datos que pasan alrededor

tengo definir un ActionFilter personalizado que hace algún trabajo y salga con algún valor. Me gustaría utilizar ese valor en acciones de controlador y en modelos.

Ahora, podría usar TempData para pasar este valor del ActionFilter a cualquier método de acción del controlador, luego distribuir este valor a todos los modelos que se pasan a las vistas devueltas.

Estoy seguro de que funcionará, pero este TempData estará allí en sesión donde y cuando ya nadie lo necesite. Se supone que el valor se utilizará exclusivamente en el código durante el tiempo de una sola solicitud, después de lo cual invalidará efectivamente.

he llegado con dos opciones:

  1. En ActionFilter, que establezca este valor en TempData en OnActioExecuting() y retirarlo en OnActionExecuted(). ¿Entiendo correctamente que para cuando se llama OnActionExecuted, la acción del controlador ha finalizado, la respuesta ya se ha generado y este contenido TempData no ha llegado a la sesión todavía?

  2. En cualquiera de mis clases estáticas personalizadas (lógica), solo defino una propiedad pública para este valor y la utilizo siempre que sea necesario. ¿Este campo estático no se perderá entre OnActionExecuting() y realmente se ejecutará el método del controlador? ¿Hay algún otro problema con la posibilidad de perder este valor durante el procesamiento de la solicitud en el servidor?

¿Hay alguna otra/mejores opciones que aún no haya considerado?

Respuesta

8

He encontrado que usar ActionParameters hace que su código sea fácilmente comprobable. Puede hacerlo de esta manera:

// inside your actionfilter 
public override void OnActionExecuting(ActionExecutinContext context) 
{ 
    var someData = // ... load some data 

    context.ActionParameters["someData"] = someData; 
} 


// and then in your action method 
[ProvideSomeData] 
public ViewResult Index(SomeData someData) 
{ 
    // someData will be populated in here 
} 
+0

Muy interesante en realidad. ¿Es así que los parámetros del constructor de acciones se asignarán automáticamente a las claves de recopilación ActionParameters? – User

+0

Sí, los parámetros de acción deben ser la forma preferida de pasar el valor en el controlador. – kazimanzurrashid

+0

En última instancia, me gustó este enfoque, aunque definitivamente niega el principio SECO. Gracias por el consejo. – User

3

re: # 2

Sólo quería señalar que el problema con un campo estático es que múltiples solicitudes serán todos utilizan el mismo campo estático. Si tiene dos solicitudes ejecutándose concurrentemente, siempre existe la posibilidad de que la solicitud B sobrescriba el valor de la solicitud A y utilizará el valor incorrecto cuando se ejecute la acción para la solicitud A.

Evitaría el uso de miembros estáticos para mantener información específica de la solicitud.

+0

Gracias. Tenía miedo de algo así. Entonces, ¿estos campos estáticos se comparten entre todas las solicitudes y no cada solicitud tiene su propio contexto? – User

+2

Derecha: los campos y propiedades estáticos públicos son visibles para cada subproceso de la aplicación. – OdeToCode

Cuestiones relacionadas