There are a couple of approaches, with varying trade-offs. Probably the two most common are:
Fetch the object from backing storage when you need it. Basically on Page_Load
you'd get the data you need using the identifier you have:
protected void Page_Load(object sender, EventArgs e)
{
var player = SomePlayerRepository.GetPlayer(User.Identity.Name);
txtFirstName.Text = player.FirstName;
// etc.
}
The SomePlayerRepository
can be implemented in any number of ways. It can include in-memory caching so that it doesn't have to hit the database over and over again, for example.
Or:
Fetch the object initially and store it somewhere local to the application. This is very similar to the "caching" mentioned above, it's just more explicit and less abstracted. For example, you might store it in Session
:
var exists = login.ValidateLogin();
if (exists == 1)
{
Session["CurrentPlayer"] = SomePlayerRepository.GetPlayer(txtUserName.Text);
FormsAuthentication.RedirectFromLoginPage(txtUserName.Text, false);
}
then in Page_Load
:
protected void Page_Load(object sender, EventArgs e)
{
var player = (Player)Session["CurrentPlayer"];
txtFirstName.Text = player.FirstName;
// etc.
}
Other options could include storing it in the user's cookie.
Personally I prefer the first approach because it separates the fetching/caching/etc. logic from the page logic, providing a common application-wide (or domain-wide perhaps) interface for the pages to use. This decouples different components of logic allowing you to modify/replace components with minimal effort.