Click here to Skip to main content
15,887,135 members
Articles / Web Development / ASP.NET
Tip/Trick

Data Passing Mechanism in MVC Architecture

Rate me:
Please Sign up or sign in to vote.
4.62/5 (8 votes)
8 Oct 2014CPOL2 min read 31.8K   11   2
Methodology of passing data in MVC architecture

Introduction

In ASP.NET MVC, there is no view state, no behind code and no server controls. As there is no view state, how will we be able to pass data in MVC architecture. There are certain mechanisms to pass data which are as follows:

  • ViewData
  • ViewBag
  • TempData
  • Session

ViewData

  • ViewData is a property of ControllerBase class.
  • ViewData is used to pass data from controller to corresponding view
  • Its life lies only during the current request. If redirection occurs, then its value becomes null. It’s required typecasting for getting data and check for null values to avoid error.
  • ViewData is a dictionary object that is derived from ViewDataDictionary class.

And we can use like ViewData["MyData"]:

C#
public ViewDataDictionary ViewData { get; set; }

ViewBag

  • The syntax of viewdata is bit cryptic as we need to use [, " for each data. So viewbag comes into the picture in those cases. Viewbag makes viewdata syntax easy.
  • Basically, it is a wrapper around the ViewData and also used to pass data from controller to corresponding view.
  • ViewBag is a dynamic property that takes advantage of the new dynamic features in C# 4.0. Dynamic property, in runtime it tries to figure out mytime property is present or not. It is the C# reflection.
  • ViewBag is a property of ControllerBase class.
  • Its life also lies only during the current request.
  • If redirection occurs, then its value becomes null.
C#
public Object ViewBag { get; }

TempData

  • ViewData or viewbag does not maintain data from action to action or controller to action. These maintain data from controller to view only. So in order to persist data for the whole request, the TempData can be used.
  • TempData is used to pass data from current request to subsequent request meaning redirecting from one page to another.
  • Its life is very short and lies only till the target view is fully loaded.
  • Its required typecasting for getting data and check for null values to avoid error.
  • TempData is a dictionary object that is derived from TempDataDictionary class and stored in short lives session. TempData is a property of ControllerBase class.
C#
public TempDataDictionary TempData { get; set; }

Session

  • For a complete request that is from controller to controller or action to action and also for the subsequent requests, the data can be persisted with the session variable.
  • Session is also used to pass data within the ASP.NET MVC application and unlike TempData, it never expires.
  • Session is valid for all requests, not for a single redirect.
  • It’s also required typecasting for getting data and check for null values to avoid error.
  • Session is an object that is derived from HttpSessionState class. Session is a property of HttpContext class.
C#
public HttpSessionState Session { get; }

Here, we can see there are many options to pass data in MVC application. In order to make the full utilization of memory and garbage collector, we need to choose our data passing variables as per our needs.

Hope the above documentation for the data passing variables in MVC will be helpful.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer
India India
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
QuestionSession Data DOES expire Pin
Peter Shaw26-Oct-14 4:29
professionalPeter Shaw26-Oct-14 4:29 
Sorry but I have to correct you here. Session Data does in fact expire.

One of the biggest issues I see when getting contracted in to fix projects that have gone wrong, is the use of session stores in the belief that they never expire.

Yes, Session does allow you to maintain state for a lot longer that the afore mentioned other methods of state management, but it's still very, very fragile.

The biggest issue is folks pushing data into the session, then assuming that it will be always there. So Joe comes to a web page, enters some data, leaves the page open and heads off for some lunch.

Joe comes back after lunch, expects to pick up where he left off, but instead is greeted by data errors because the developer in the assumption that the data will remain there, never though to check to see if the app-pool had been recycled, or the session time out had expired, thus emptying the current session cache.

The ONLY way to guarantee the session data will do exactly what you need it too, is to write your own session provider, and cache this into some store such as Redis or a fast SQL database, this way when IIS decides to cycle it's app pool the only thing that you actually need to persist is a session key, and that can easily be pushed into a cookie or html5 data attribute along with the page request.

Never, Ever, Ever depend on the session as it stands with the built in objects in .NET, it WILL bite you and when it does it'll bite you hard.
GeneralMy vote of 5 Pin
Humayun Kabir Mamun8-Oct-14 16:38
Humayun Kabir Mamun8-Oct-14 16:38 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.