ViewData vs ViewBag vs TempData in ASP.NET MVC: Differences, When to Use Each, and Implementation Examples

ViewData and ViewBag are the same underlying storage – a ViewDataDictionary keyed by string, valued by object – with two different access syntaxes. ViewData uses dictionary syntax: ViewData[‘UserName’] = ‘Alice’ in the controller, @ViewData[‘UserName’] in the view, requiring a cast if you need typed access like (string)ViewData[‘UserName’]. ViewBag uses dynamic-property syntax (via C#’s dynamic type): ViewBag.UserName = ‘Alice’ in the controller, @ViewBag.UserName in the view, no cast needed. They’re interchangeable – ViewData[‘X’] and ViewBag.X access the same value. Choose based on preference: ViewBag’s dynamic syntax is cleaner for reads but provides no compile-time checking (a typo in @ViewBag.UsreName fails silently as null rather than a compile error). ViewData’s dictionary access is more explicit but more verbose. Both have the same lifetime (current request only) and the same fundamental limitations – modern ASP.NET MVC best practice is strongly-typed view models for primary page data; ViewData/ViewBag for ancillary data only.

TempData is a dictionary-like object (TempDataDictionary) designed for scenarios where data must survive a redirect. Typical example: a controller action processes a form submission and succeeds, then redirects the browser to a confirmation page – the confirmation message needs to be displayed on the confirmation page, but after the redirect the original controller action’s ViewData and ViewBag are gone (different request). TempData stores values for exactly one additional request cycle: TempData[‘Message’] = ‘Saved successfully’; return RedirectToAction(‘Index’);. The redirected-to action can read @TempData[‘Message’]; after that read, the value is marked for removal. Backed by session state by default (or cookies in newer configurations), so TempData adds session dependency. Use TempData for: post-redirect flash messages (success confirmations, error notices), short-lived data crossing a redirect boundary. Don’t use TempData for: data that should persist longer than one request cycle (use session directly), primary page data (use view models), data that doesn’t cross a redirect (use ViewData/ViewBag).

Modern ASP.NET MVC best practice: view models for primary page data, ViewData/ViewBag for ancillary supporting data only. Rationale: strongly-typed view models provide compile-time checking (typos in property names are errors, not runtime nulls), IntelliSense in the view template, easier refactoring (rename a property, see all usages update), and clearer contracts between controller and view. Pattern: define a view model class (class UserProfileViewModel { public string UserName {get; set;} public int Age {get; set;} public List<Order> RecentOrders {get; set;} }), populate it in the controller, pass to the view via return View(model), and access strongly-typed properties in the view (@Model.UserName). Use ViewData/ViewBag sparingly for: page title, breadcrumbs, layout-only data that’s not part of the view’s primary responsibility, flash messages from TempData. The general rule: if the view’s template repeatedly references the same data, that data belongs in a view model; if the data is cross-cutting layout concerns, ViewData/ViewBag is appropriate. Razor Pages (newer) has stronger guidance toward PageModel (its equivalent of view model) as the primary pattern; ViewData/ViewBag usage continues to decline in modern ASP.NET Core applications.