I have seen many posts about when to use ViewBag/ViewData vs ViewModel but i have not been able to find an explanation of the lifecycle of the ViewBag.
For example, i have two Action methods in one Controller:
// POST: /MyModel/Edit/5
[HttpPost]
public ActionResult Edit(MyModel _mymodel){}
and
// GET: /MyModel/Edit/5
public ActionResult Edit(int id){}
If i put some values in the ViewBag in the GET action method, to set up some Form labels, then when they user clicks 'Submit' button and the Form is posted back to the server via HTTP POST, the ViewBag values are no longer within the POST action method.
Can someone please explain (or provide reference to good article) the lifecycle of the ViewBag/ViewData ?
The data you put in the ViewBag/ViewData is only available during the life-cycle of the request within which you populated it. MVC does not have post backs. If you need something to persist over more than a single request, you should use Session.
Here is a decent article about the differences between ViewData, ViewBag, and TempData: http://rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications
The accepted answer here doesn't really describe the lifecycle of ViewBag/ViewData. It's unfortunate there appears to be no clear documentation about this. However, based on this:
http://blogs.msdn.com/b/varunm/archive/2013/10/03/understanding-of-mvc-page-life-cycle.aspx
It would seem the lifecycle is:
IIS request -> Routing -> MVC Handler -> Controller (with ViewData) -> View (with ViewData) -> Disposal
So, the ViewData (which ViewBag simply wraps) would actually be instantiated with the ControllerContext, at the same time TempData is instantiated. This occurs a few steps after Step 4: MVC Handler Executes.
There's an interesting step later where "If the Page has ViewData, the ViewData is set" during the handoff from Controller to View. ViewData is clearly available prior to this, so set can't mean instantiate. It appears to instead mean it's transferred from the Controller (which remember isn't available to a View) to the ViewContext (the container that provides the View access to ViewBag/ViewData, and Model).
The ViewData is presumably disposed of at the same time as the rest of the View.
It's important to also note that MVC Views are rendered from the inside out, so the particular View and any assignments it makes to the ViewBag will occur likewise in the order of inside to outside. That means something set on a View child page will be available to a Layout, but adding something to a ViewBag in a Layout and then reading it in a View child page will fail.
From MSDN - ViewBag: The dynamic view data dictionary, ViewData: The dictionary for the view data.
So these/this is a dictionary for a given view. You set its values in your action and you use it in your view. As Zach said it's not coming back with the subsequent request. You can send its values back to any given action as a form field, in querystring, etc, but these values won't be automatically available as VieBag's properties.
ViewBag
and ViewData
are used for the same purpose. They are used to pass data from controllers to the View. When we assign any data or object to them they are accessible in the View.
ViewData
: ViewData
is a dictionary of objects and they are
accessible by string as key.
ViewBag
: Uses the dynamic feature. It allows an object to add
dynamic properties to it.