26

Voglio assicurarmi che un particolare parametro in QueryString, nel mio caso lo request_id venga propagato all'azione reindirizzata.Propagazione del parametro QueryString nelle chiamate RedirectToAction

Diciamo per esempio, ho un azione First,

[HttpPost] 
public ActionResult First() 
{ 
    //////////////////// 
    // Lots of code ... 
    //////////////////// 

    return RedirectToAction("Second"); 
} 

Ora dicono, il postback First aveva un parametro nel QueryString, che vorrei passare all'azione Second. Un modo per farlo sarebbe quello di passare il valore nel RedirectToAction chiamata stessa,

string requestId = Request.QueryString[REQUEST_ID_KEY]; 
return RedirectToAction("Second", new { REQUEST_ID_KEY = requestId }); 

ma devo fare questo in una serie di azioni e io sono disposto a integrare la logica di propagazione richiesta id dentro l'azione. Sarebbe meglio se potessi incorporare questo in un ActionFilter, ma non riesco a capire come aggiungere parametri a QueryString da un ActionFilter. Qualche idea?

risposta

48
public class PreserveQueryStringAttribute : ActionFilterAttribute 
{ 
    public override void OnActionExecuted(ActionExecutedContext filterContext) 
    { 
     var redirectResult = filterContext.Result as RedirectToRouteResult; 
     if (redirectResult == null) 
     { 
      return; 
     } 

     var query = filterContext.HttpContext.Request.QueryString; 
     // Remark: here you could decide if you want to propagate all 
     // query string values or a particular one. In my example I am 
     // propagating all query string values that are not already part of 
     // the route values 
     foreach (string key in query.Keys) 
     { 
      if (!redirectResult.RouteValues.ContainsKey(key)) 
      { 
       redirectResult.RouteValues.Add(key, query[key]); 
      } 
     } 
    } 
} 

e poi:

[HttpPost] 
[PreserveQueryString] 
public ActionResult First() 
{ 
    //////////////////// 
    // Lots of code ... 
    //////////////////// 

    return RedirectToAction("Second"); 
} 
+1

@Darin .. Solo per la conoscenza .. Posso sapere qual è il vantaggio di questa implementazione su Session o TempData? –

+2

@alok_dida, TempData utilizza Session dietro le quinte. Personalmente non uso mai Session nelle mie applicazioni. Preferisco disegnarli in modo apolido e RESTful. Quindi, poiché disabilito la sessione in web.config (''), beh, Session e TempData non si applicano per me. –

+0

@Darin .. Oks. Ancora una domanda (spero che non ti arrabbi con il mio gruppo di domande), sto implementando un'applicazione che usa l'autenticazione della forma. Voglio mantenere "UserID" dell'utente connesso attraverso l'applicazione. Come posso implementare questo scenario senza usare Session? Sto usando MVC 3. –

0

Se ne hai bisogno nell'azione successiva, aggiungilo come parametro in Session o TempData (ma devi riassegnarlo in ogni azione) in modo da non doverlo passare come una sequenza di query in ogni azione. In caso di sessione, una volta terminato con tutte le azioni, rimuovere quella chiave dalla sessione.

+0

mi serviranno i dati nel postback troppo .. quindi devo passare nel QueryString –

+0

È possibile ottenere facilmente i dati dalla sessione finché non si rimuove la chiave dalla sessione in modo che i dati siano disponibili anche nell'azione postback. –

Problemi correlati