ASP.NET Web API：如何跨请求创建持久集合？

Question

I have a Web API providing a backend to an Angular.JS web application. The backend API needs to track the state of user activities. (Example: it needs to note which content ID a user last retrieved from the API)

Most access to the API is authenticated via username/password. For these instances, it works fine for me to store the user state in our database.

However, we do need to allow "guest" access to the service. For guests, the state does need to be tracked but should not be persisted long-term (eg session-level tracking). I'd really like to not have to generate "pseudo users" in our user table just to store the state for guest users, which does not need to be maintained for a significant period of time.

My plan is to generate a random value and store it in the client as a cookie. (for guests only - we use bearer authentication for authenticated users.) I would then store whatever state is necessary in an in-memory object, such as a Dictionary, using the random value as a key. I could then expire items off the dictionary periodically. It is perfectly acceptable for this data to be lost if the Web API is ever relaunched, and it would even be acceptable for the dictionary to be reset say, every day at a certain time.

What I don't know how to do in WebAPI is create the dictionary object, so that it will persist across Web API calls. I basically need a singleton dictionary object that will maintain its contents for as long as the server is running the Web API (barring a scheduled clearing or programmatic flushing)

I had the idea of dumping the Dictionary off to disk every time an API call is made, and then reading it back in when it's needed, but this does not allow for multiple simultaneous in-flight requests. The only method I can think of right now is to add another database table (guest_state or something) and replicate the users table, and then setup some sort of manual method to regularly clean out the data in the guest table.

Summary: what I need is

• a way to store some data persistently in a Web API backend without having to go off to a database
• preferably store this data in a Dictionary object so I can use randomly-generated session IDs as the key, and an object to store the state
• the data is OK to be cleared after a set period of time or on a regular basis (not too frequently, maybe a minimum of a 6 hour persistence)

Answer 1

I figured out a solution using the Singleton pattern:

public static class Services 
{
    private static Dictionary<string, string> cache;

    private static object cacheLock = new object();
    public static Dictionary<string,string> AppCache
    {
        get
        {
            lock (cacheLock)
            {
                if (cache == null)
                {
                    cache = new Dictionary<string, string>();
                }
                return cache;
            }
        }
    }
}

public class testController()
{
    [HttpGet]
    public HttpResponseMessage persist()
    {
        HttpResponseMessage hrm = Request.CreateResponse();
        hrm.StatusCode = HttpStatusCode.OK;

        Services.AppCache.Add(Guid.NewGuid().ToString(), DateTime.Now.ToString());

        string resp = "";

        foreach (string s in Services.AppCache.Keys)
        {
            resp += String.Format("{0}\t{1}\n", s, Services.AppCache[s]);
        }
        resp += String.Format("{0} records.", Services.AppCache.Keys.Count);

        hrm.Content = new StringContent(resp, System.Text.Encoding.ASCII, "text/plain");
        return hrm;
    }        
}

It seems the Services.AppCache object successfully holds onto data until either the idle timeout expires or the application pool recycles. Luckily I can control all of that in IIS, so I moved my app to its own AppPool and setup the idle timeout and recycling as appropriate, based on when I'm ok with the data being flushed.

Sadly, if you don't have control over IIS (or can't ask the admin to set the settings for you), this may not work if the default expirations are too soon for you... At that point using something like a LocalDB file or even a flat JSON file might be more useful.