ASP.NET Storing Cross Request Data

Question

In my application I have this entity:

public class Franchise
{
    public Guid Id {get;set;}
    public string Name {get;set;}
}

When each of my users log in, they are associated with a franchise.

There is another entity:

public class Client
{
    public Guid FranchiseId {get;set;}
    public virtual Franchise Franchise {get;set;}

    public string Name {get;set;}
    /* other useful client information */
}

Depending on my user franchise association will determine which clients they shall see (or are allowed to see)

So equivalent of doing

dbContext.Set<Client>().Where(x => x.FranchiseId.Equals(associatedFranchiseId));

I was wondering what the options where of storing that associatedFranchiseId so each request for data can use that Id to select the appropriate dataset.

APPROACH 1

I created a service that gets these associations and returns the correct dataset. I thought I could use this in each controller where I need to get the information. But I thought this maybe costly in database lookup terms. It would have to based on the User, so getting that out of the request.

I just am not sure how I would go about doing this.

The process is:

1. User Logs In
2. Application determines the associated franchise
3. User request some information
4. The request uses the associated franchise to select the right dataset

Answer 1

I've used something similar and use the session and application spaces for the objects.

So, when the application fires up load all the franchise objects into application :

Application["Franchise"] = MethodToLoadFranchiseInfo();

You can then access this at anytime via Franchise f = Application["Franchise"];

Similarly, for the clients, when they login, load the client info into Session in a similar fashion.

The only caveat if that you'll need to refresh the Application object when there's an update, and same for the session, or require a log out and log back in.

This way you only have one hit to the database and in memory accessible objects!

* Edit to Add *

Just had some more thoughts on this, and probably something I'll look to implement myself. If you put a timestamp in both the application and session objects, if the session object is older than the application object (which will be updated centrally being application wide), then hit the database and refresh the session object.

That way you do not get the log out / log back in situation when something is changed by the backend / admin.