Is RedirectToAction in C# expensive?

Question

I've some code like the following;

We're going to create a Note but we may know the CustomerId when we do so I've two URLs;

public ActionResult CreateByCustomer(int id)                                        
{
    Session["ncAppointmentId"] = 0;
    Session["ncNoteDate"] = null;

    SetConsultant(0);
    return RedirectToAction("Create", "Note", new { id = id });
}

public ActionResult Create(int id = 0)
{
    int _CustomerId = id == 0 ? Convert.ToInt32(Session["CustomerId"]) : id;
    Session["TemplateIds"] = null;
    and so on.......
    ViewBag.CustomerId = _CustomerId;

When I look at the performance in Firebug the RedirectToAction causes a GET with a '302 Found' status which can incur up to 1 second's delay.

If I change the RedirectToAction line to

    return Create(0);

Then the GET doesn't happen and performance is improved.

But I'm looking for opinions on what the downside is or what I've missed ?

Answer 1

The RedirectToAction result tells the client to request a new page, so it will naturally incur overheads since the client is now having to make a second request to your server. Sometimes this is necessary, sometimes - as in your example - not.

Generally I use RedirectToAction to return the client to a specific page after performing an action such as creating a note. This can be useful if you're on a page that lists notes and you want to refresh the page after creating a new one. The end result is that the page is refreshed, and the Create action does not appear in the user's browser history.

If your Create method returns a View, there can be some interesting side effects of calling it directly. In general the MVC code will handle it, but you can get some weird results - like the client's URL being different to what you expect in the subsequent requests, etc. If you're OK with this, fine.

Another option would be to get rid of the CreateByCustomer action and simply call the Create view with a parameter - named customerID for instance. This gives you the same ability to call it different ways without having to have multiple entry points. The client's location would reflect (in the query string) the difference between Create and Create?customerId=12345 which may or may not be what you're after.

---

<opinion>
Some Style Notes:

• If you're storing lots of session data, create a class to hold it instead of creating lots of entries in Session[].

• It's not particularly difficult to use jQueryUI to create an in-page editor for your notes rather than defining a view - check out this example. More elegant too :P

</opinion>