1

I am fairly new to MVC and had some questions about maintaining state in MVC:

1: I understand that the controller can provide state data to the view via the ViewBag, ViewData, etc. but how does one get this state data back to the controller from the view? It seems like the use of ViewBag, etc. is just a one-way trip which is no good for maintaining state.

2: With MVC is the use of Session frowned upon or seen as the "old way" to manage state? If so, how does one manage state without a "global" tool like Session.

I have searched online for answers to these questions, but have so far only found incomplete answers.

Also, if it matters, I am using MVC 5 with Entity Framework 6.

flying227
  • 1,231
  • 3
  • 22
  • 36
  • I suggest you look at the tutorials on [asp.net](http://www.asp.net/mvc/tutorials). They'll get you started with the basics. – germi Apr 25 '14 at 13:26
  • ViewBag and the sorts is generally a bad idea and you want to try to avoid using them. That is why you use Models. Controller passes Model to View, View passes Model back to Controller. http://www.asp.net/mvc/tutorials/mvc-4/getting-started-with-aspnet-mvc4/intro-to-aspnet-mvc-4 – CSharper Apr 25 '14 at 14:17

2 Answers2

0
  1. ViewBag is indeed one-way. It's not intended for persistence of data, and frankly, its use should be avoided almost entirely. With rare exception, anything you think you might need ViewBag for is better done using a view model.

  2. Not sure where you got the idea that sessions are frowned upon or are some how the "old way". Sessions are how state is preserved on the web, there's nothing else. How you handle sessions is open to debate (cookies, in-memory, database-persisted, etc.), but there's nothing wrong with using sessions in general.

(As a caveat to #2 above, it's worth mentioning that I'm speaking in terms of web sites or applications. If you're talking about an API, that's an entirely different can of worms. APIs, at least those that follow REST conventions, totally discourage sessions. Sessions are the antithesis of REST, which among other things, relies on the stateless nature of protocols like TCP.)

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
0

Actually, the data you send using the ViewBag can be sent back to the controller via GET and POST parameters (its how ALL data are sent back). More about get and post

The following is an example on passing data back and forth using ViewBag (output) and <input type="hidden" /> (input)

public class HomeController : Controller
{
    public ViewResult Edit()
    {
        // Lets send this one, and see if the view can return it.
        ViewBag.UserID = 1; 

        return View();
    }

    [HttpPost]
    public ActionResult Edit(int userID)
    {
        int userID = userID; // Place a breakpoint here and verify our little test.
        return View();
    }
}

// This is your view
@using (Html.BeginForm()) {

    <input type="hidden" value="@ViewBag.UserID" />
    <input type="submit" value="Save" />
}

Managing the State

Using ViewBag for passing the state is not uncommon, like for instance managing the page index for a paging functionality. In those cases, we wouldn't want to create a ViewModel just for a single property(PageIndex) that has no relation whatsoever with the model. As long as your intentions are obvious, then I would say keep it simple.

The proper usage of sessions depends on the type of state that you are trying maintain (and the business requirement). If you are managing the state of the UI using sessions, then that is bad. But if you are trying to protect the state like a user account id, in a site that demands security like banking website, then sessions are highly recommended if not the only acceptable.

Session is a tool, and like most tools, if abused are frowned upon.

Different types of state should be manage not by one method, but by many different methods.

Ways to manage the state

Community
  • 1
  • 1
Yorro
  • 11,445
  • 4
  • 37
  • 47