c＃+ WebForms + static - 最佳实践是什么？

Question

I'm definitely not a fan of WebForms, I prefer in the .NET world ASP.NET MVC.

Regardless, I'm working on a small part of a very large legacy WebForms application.

I'm integrating Korzh.com's EasyQuery.NET. to allow end users to create their own SQL queries based on pre-defined models made user friendly with aliases.

This is relevant because Korzh's demo uses Global.asax for its model and
query class along with Session.

Because the legacy WebForms application is very large, Global.asax in not used
for page specific items.

My solution was to use private static instead. static works well in desktop
applications but seems at the very least likely to cause some grief in WebForms applications.

I've discovered that !IsPostBack is not too reliable and it seems to me that
in WebForms the best practice may be to use Session. The problem with
Session is that it seems to be passed to the client with the HTML and can grow
very large in kilobytes.

QUESTIONS:

Since static variables reside on the IIS server when used with WebForms, does every user of a WebForms application share the same static variable address space? (I think the answer is yes).

What are the best practices/guidelines for using/not using static variables with ASP.NET WebForms applications?

Thank you.
Regards,
Gerry (Lowry)

PS: I could not find answers
via Google or searching SO.

Answer 1

In ASP.NET, static instances will live for the lifetime of the application, that being the web application itself, until it is recycled, or shutdown, eg:

public class Global : HttpApplication {
    public static string MyString
}

Because of this, the static property is accessible for all requests made to the application. Not the place to be storing page-specific items. There are quite a few storage mechanisms available:

1. HttpRuntime.Cache and HttpContext.Cache, both point to the same cache instance, and items exist for the lifetime of the application (so has the same issues as static instances).

2. HttpContext.Items, a request specific collection of items. Each request made to the application will have its own collection of items.

3. HttpSessionState session, persisted for the length of the user visit, or whenever it times out. This can be configured 4 ways:

   3.a. InProc, session objects are stored in memory by the worker process itself. Fast accessing cache, doesn't require serialisation, but if the application recycles, the session data is lost.

   3.b. SqlServer, session objects are serialised and stored in a Sql Server database. Requires all session-stored items to be serialisable. Session objects persist even when an application recycles.

   3.c. StateServer, session objects are stored in a seperate process, and persists data through application recycles.

   3.d. Custom session provider, that's up to you....

4. ViewState, this is where data is persisted to the client-side and is posted back to the server to rebuild control states between page views.

I would avoid using static instances and the HttpRuntime cache for anything user related. Use these mechanisms for shared, common information, such as configuration, caching, etc. Session is likely the place you want to store things on a per-user basis. If you are looking for a per-page solution, its a lot simpler, because you simply make the variables part of the page structure itself, as properties or fields. You just have to manage the initialisation of these fields.

Hope that helps.