TempData, ViewBag and ViewData — Passing Data to Views

Controllers need to pass data to views. The primary mechanism is the strongly-typed ViewModel passed to View(model) — this is always the preferred approach. But ASP.NET Core also provides three convenience mechanisms for passing auxiliary data: ViewBag (dynamic), ViewData (dictionary), and TempData (survives one redirect). Understanding when each is appropriate and when to reach for a ViewModel instead prevents scattered, hard-to-maintain data passing patterns.

ViewBag and ViewData #

// ── ViewData — dictionary, string keys, object values ─────────────────────
// Lives for ONE view render (not across redirects)
public IActionResult Index()
{
    ViewData["Title"]    = "All Posts";           // page title
    ViewData["Category"] = "Technology";          // auxiliary data
    return View(new PostIndexViewModel(posts));
}

// In the view:
// <title>@ViewData["Title"]</title>
// <p>Category: @ViewData["Category"]</p>

// ── ViewBag — dynamic wrapper around ViewData ─────────────────────────────
// Syntactic sugar over ViewData — same lifetime, same storage, just nicer syntax
public IActionResult Index()
{
    ViewBag.Title       = "All Posts";   // same as ViewData["Title"]
    ViewBag.PageNumber  = 1;
    ViewBag.IsAdmin     = User.IsInRole("Admin");
    return View(model);
}

// In the view: @ViewBag.Title  @ViewBag.PageNumber
// Both ViewData and ViewBag share the same underlying dictionary.
// ViewData["Title"] == ViewBag.Title — they are the same value.

TempData — Surviving Redirects #

// ── TempData survives exactly ONE redirect ─────────────────────────────────
// Set in POST action, available in the next GET action (after redirect)

// POST action — sets TempData before redirecting
[HttpPost, ValidateAntiForgeryToken]
public async Task<IActionResult> Create(CreatePostViewModel model)
{
    if (!ModelState.IsValid) return View(model);

    var post = await _service.CreateAsync(model.ToRequest());

    // TempData survives the redirect
    TempData["SuccessMessage"] = $"Post '{post.Title}' created successfully!";
    TempData["NewPostId"]      = post.Id;   // integer, auto-serialised

    return RedirectToAction(nameof(Index));  // redirect to GET
}

// GET action — TempData available here (cleared after this render)
public async Task<IActionResult> Index()
{
    var posts = await _service.GetPublishedAsync(1, 10);
    return View(new PostIndexViewModel(posts));
    // TempData["SuccessMessage"] is rendered in the view, then cleared
}

// ── TempData.Peek — read without clearing ─────────────────────────────────
// Normal TempData read: marked for deletion, cleared after render
string? msg = TempData["SuccessMessage"] as string;  // will be cleared

// Peek: read without marking for deletion (available in next render too)
string? msg2 = TempData.Peek("SuccessMessage") as string;  // stays for another render

// Keep: prevent TempData from being cleared after this render
TempData.Keep("SuccessMessage");  // keep for one more render

When to Use Each Mechanism #

Common Mistakes #

Mistake 1 — Using TempData to pass large amounts of data (cookie size limit) #

❌ Wrong — large objects in TempData exceed the 4KB cookie limit; TempData silently fails.

✅ Correct — pass only small strings (success/error messages) in TempData; pass large data via session or re-query it in the next action.

Mistake 2 — Using ViewBag for data that should be in the ViewModel #

❌ Wrong — core page data in ViewBag; typos not caught at compile time:

ViewBag.TotalPosts = await _service.CountAsync();   // magic string, easy to mistype

✅ Correct — add TotalPosts to the ViewModel where it is type-safe and checked at compile time.