Developing Web Applications

Selecting Object Scope

Components can exist and operate within the scope of an application or session, or they can be created and destroyed on a page-by-page basis.

Objects stored in the Application object are available to all users of the application. The Application object is a suitable place to store objects that have no user affinity, such as a page counter. Normally, values and objects with application scope are created when the application begins, and are accessed in a read-only fashion by users of the application. When you make changes to Application object values, you should use the Lock and Unlock methods to prevent users from accessing data while it is changing.

In general, very few objects should be given application scope. They should support the “Both” threading model, as “Apartment” threaded objects force the Application object into a single thread of execution, and free-threaded components tend to be slower overall. COM components should not be given application scope, because they would be created when the application starts up, even though they might not yet be needed.

Because the Session object is designed to store information about the current user’s session, components stored in this object can exist as long as the user’s session is active. Since each value and object stored in the Session object increases the server’s memory requirements for each user of the application, you should store values for only as long as they are necessary, and free them when they are no longer needed.

Page-scope objects are created each time the page is requested. They can use any threading model, but only the “Apartment” and “Both” models are recommended for scalability purposes.