ViewBag and ViewData do not preserve state, but they can pass it to view and save views.
What are ViewBag and ViewData ?
ViewBag and ViewData are not ViewBag mechanisms, but I believe that they are part of state management: they are mechanisms for transferring data to a page, which can then be saved as state in the generated html. Thus, they are part of the state life cycle, since they allow you to store state in the html client side using helpers such as @Html.HiddenFor or @Html.ActionLink .
In my answer to "saving the js value from 1 ActionResult for use in another ActionResult" I will talk about how ViewBag and ViewData can be used to save state in client html and what are various options for storing state.
As for the ViewBag , this is actually a way to ViewBag access the ViewData , so ViewBag.MyItem = "foo"; and var valueEqualsFoo = ViewData["MyItem"]; will set and return the same string and can be used interchangeably.
What do they look like?
ViewBag , ViewData most closely related to the View Model in Action, where the model is passed to the view inside the Action using return View(viewModel); : all three methods transfer the state in memory to html, where it is sent to the client, to any intermediate caches and is "saved" from your server.
Similarly, when a request string in a URL is sent to the server in an HTTP request, this is a state transfer method, the actual state store is the anchor <a href="urlwithquerystring">...</a> in html. The remaining URLs and bodies for ajax POST requests are the same in their definition and behavior. ViewBag/Data pass the state from Action to html, which is passed to the client and saved, the query string or a calm URL, then passes the state back to the server for use in the next Action call.
When should you use them?
It is difficult to verify dynamic properties with an error in the Razor code; it is easy to check if a property exists in a strongly typed representation model. Therefore, I believe that you should use them very rarely. In my opinion, it is preferable to create highly typed view models rather than using a ViewBag or ViewData . They may be good for a quick and dirty solution , but these things tend to create Technical Debt . ViewBag may be suitable for setting the page title.
Strongly Typed Models:
- Simplify the use of mapping with frameworks such as automapper
- make browsing more reliable; and
- Simplify the creation of different views for different devices, where you pass the same model to each view & dagger;
What are my options for storing state?
I said this here , and I will say it again: there used to be Nine Permanent User State Management Settings in ASP.NET , and many of them are still used in MVC. They all have different uses depending on how the state should be used. As a rule, server code, which is as independent as possible, is easier to test and debug.
- Client-side storage includes:
- The objects returned in the html result turned into:
- Input fields
- Hidden fields
- Javascript variables for use in ajax POST objects
- Query string strings and paths in URLs (e.g. recovery URLs such as
/Product/1 )
- Older ASP.NET methods that save state in hidden html fields like
ViewState - Cookies
- Html5 methods such as Local Storage
- Counterfeit Attributes Generated to Prevent XSRF
- Server-side storage (directly related to ASP.NET and ASP.NET MVC):
- Server-side storage (other):
- Databases, whether SQL or NOSQL
- File storage
- Message Queues such as WASB
Footnote:
& dagger; Now we have an easy-to-use tool for flexible design , which we can use when it suits , but it does not always work: some types should look completely different on mobile devices , but still use the same viewing model as the site big screen.