Tempdata vs Session in Asp.net MVC

Why Sessions are Not Recommended to use in MVC

One of the Fundamental Principal of Asp.Net MVC Framework is  Web is Stateless And AspDotNet MVC is Stateless AspDotnet WebForms is a try to make Stateful Modal But Its difficult to main it as this modal does not exist . Sessions Create lot of load on Cache that was biggest problem .

Using Session in AspDotNet MVC is like Putting APPLE Logo on Asus Laptop and Calling it Apple Laptop . Reality does not change .

What Is Alternative To Session in MVC

You can use TempData in place of Session . Tempdata is limited form of Session . Don’t Use Session in MVC as you are already having Tempdata and one benefit of Using Tempdata is They will automatically deleted no need to clear or remove them as we do with session

How To Use TempData In MVC

When Data is TempData is read it is immediately market for deletion at the end of request . That means you can use Value Tempdata In Tempdata Only at the Next Request . See Example Below - 

TempData is Filled With Data

TempData["SomeTemp"]= "Hey! This is MVC" ;

Tempdata Accessed in Second Request 

Object value = TempData["SomeTemp"] ;

Value in Tempdata will be Cleared After Above Line of Code . If you access in after that line of code after above line you will not found it there it will be deleted

Keep And Peek Methods 

Peek And keep methods are used to read value without marking it for deletion after reading its value . So it is acutally helping us to retain its after its first read instead of deleting tempdata

With Peek Method We get the value of Tempdata Without Marking it For Deletion . In this method we access the Tempdata value using Peek Method That tells it to Hold Value and does not mark it for deletion

With Keep Method we hold the Value of Tempdata that was marked for Deletion after its  first read . so it is using two different calls . First one is getting Tempdata Value then Second call is To Save Tempdata From Deletion

Using Entity Framework Code First Migration Asp MVC

 Code First Database Initializers

 Before understanding code first migrations, let's have a look at Code First Database Initializers   provided by Entity Framework. When you follow EF code first approach, then you have three op tions for initializing database as given below–

1. CreateDatabaseIfNotExists

   This is the default database initializer class used by Code First. This class creates a database only if it doesn't exist. This initializer helps you to avoid any accidental deletion of the database.
   

2. DropCreateDatabaseWhenModelChanges

   This database initializer class drop the existing database and re-creates it if there is a mismatch between the model classes and table schema. This initializer is useful during starting phase of development and testing when models are changing often and there is no concern about the existing database records.
   

3. DropCreateDatabaseAlways

   This database initializer class always drop and creates a new database, whether it is already present or not with every run of the application. This initializer is useful during testing when you want to run the application with a fresh set of data.
   
   

   Why Code First Migrations?

   The above three database initializing approach become fail when you add new model classes and you want to update existing database without any deletion or change. To achieve this, you need to use EF code first migrations which allow you to update existing database with new model classes changes and your existing database remains same with your database records.
   
   

   Visual Studio Package Manager Console

   To create the database for these two entities within your application, go to the Package Manager Console option as shown below:
   
   

   Creating New Database

   Running Commands

   Run the following command to configure migrations within your project and for creating new database.
   

4. Enable migrations

   Enable-Migrations

5. Create migration

   Add-Migration MigrationsName

6. Create upgrade/downgrade script

   Update-Database
   
   

7. Updating Existing Database

   Suppose you have added one more class named as Customer into your data model classes as given below:
   
   

   Running Commands

   Now for updating the database with new changes run the following commands as given below:
   

8. Create migration

   Add-Migration MigrationsName

9. Create upgrade/downgrade script

   Update-Database