An ASP.NET Core 3 web application is normally stateless. A brand new Razor web page is instantiated every time there is a request for the page from the server. As a result, any bit of data in the Razor page is effectively lost for each back and forth request.

To put things into perspective, we have already looked at a UserRegistration page, and if we inspect the browser with the developer tools, we will notice that when we fill the form and submit, our data is sent to the server but the data is not returned to the browser in the response headers.

This is the natural impediment of producing a meaningful and interactive application for the web, and we are lucky that ASP.NET Core 3 deals with this impediment for us with inbuilt features.

One of the ways we can make a decision on what feature functionality to use is by asking some of the following questions:

• Are we going to need to keep a lot of data between the requests?
• What are the chances that the user client will accept different kinds of cookies?
• Do we want the data to be stored by the server or client?
• Is the data in question delicate in that we need to keep it secure?
• Are we writing the application for user or client browsers that cannot afford high bandwidth usage?
• Exactly what kind of devices will be accessing our application? Do they have limitations?
• Will every application user need personalized data?
• How long do we need the application data to be persisted?
• Are we going to host our application in a distributed environment with multiple instances or a normal environment with a single instance?

Let's take a look at the options we have for managing states, along with their advantages.