 |
|
devtutor: Working With the Session in ASP.NET
The Application in ASP.NET
ASP.NET, like its predecessor,
provides a utility for maintaining state for common elements used by any
of the visitors to your web application: the Application object. The .NET version
of the Application object, like the .ASP
version of the Application object, provides an easy to use mechanism to store
common information for your application based on a key-string collection.
Much like the .NET Session object, the new Application object,
coupled with some very powerful classes in the .NET framework, allow for a
powerful and easy to use/code site management object. This tutorial is designed
to present you with a set of guidelines for when and how to best make use of
the Application object.
When (and What) the Application Should be Used
The Application object is intended to be used to
maintain application wide state for your application. As such, it should maintain information
and provide functions/methods that are either global in nature, or generically
support any custom Session objects.
Care must be taken when planning the life cycle
of the Application object. The Application is initialized
when the first visitor comes to your site and stay in existance (i.e. memory
resident) until the web services are stopped or restarted. As the
application object is continuously available, it's memory overhead should be
kept as low as possible or steps must be taken to unload resources after a given period of
time. Furthermore, any application calls that make use of other server based
objects (files, databases, etc.) should be opened and closed appropriately; generally on
a per method basis. Resources should never be left open between method
calls as this can lead to resource access conflicts and, thus, poor
performance. Finally, as the Application object is a shared resource, care must
be taken when modifying its properties (appropriate "locks" and "unlocks" are imperitive).
Planning an Application
Let's continue from the example started in the Session
tutorial. To support the Session's SendFeedback method, three standard
properties (FeedbackReciepent, Subject, and BodyTemplate). As such, the Application object
will look something like this:
using System;
namespace feedbackForm
{
public class ApplicationFeedback
{
/*
The m_MailSettings variable is a strongly typed System.Data.DataRow
object used for storing related items. For more information on
strongly typed Data objects, please refer to the DataSet tutorial.
*/
private DsStorage.MailSettingsRow m_MailSettings;
public string
FeedbackRecipient
{
get { return m_MailSettings.Recipient;
}
}
public string Subject
{
get { return m_MailSettings.Subject; }
}
public string BodyTemplate
{
get { return m_MailSettings.Body; }
}
}
}
|
Accessing the Application
Like the older ASP
Session model, the ApplicationState utility is a keyword indexed collection. As in
the Session tutorial, we will be accessing the Application object through a Current property
to avoid having to expose the keyword to the ASP.NET
application. This technique is accomplished by making use of the "Current"
property of the System.Web.HttpContext class (which allows objects outside of
the web page to access the web page's context).
To access the Application, a static property on the Application is
used to reference the current Application or, if it doesn't exist, to create
it. Please note the two additions to the Application class; the private
constructor and the public, static Current property. In order to support these additions,
two library references have been added as
well as a supporting private variables.
using System;
/* Added library references. */
using System.Web;
namespace feedbackForm
{
public class
ApplicationFeedback
{
private DsStorage.MailSettingsRow
m_MailSettings;
/* Private Constructor */
private ApplicationFeedback(string datasetPath)
{
DsStorage ds =
new DsStorage();
ds.ReadXml(datasetPath);
m_MailSettings = ds.MailSettings[0];
}
public string FeedbackRecipient
{
get { return
m_MailSettings.Recipient; }
}
public string Subject
{
get { return
m_MailSettings.Subject; }
}
public string BodyTemplate
{
get { return
m_MailSettings.Body; }
}
/* Public, static "Current" property */
public static ApplicationFeedback Current
{
HttpApplicationState app =
HttpContext.Current.Application;
ApplicationFeedback myApp = null;
myApp =
((ApplicationFeedback)(app["ApplicationFeedbackKey"]);
if (myApp ==
null)
{
/* Please note that to create the application object, the file path
to the XML file containing the application settings is needed. This
information is determined by using the MapPath method and the root-relative
path to the data file. Also, note that when the application is added to the
HttpApplicationState object, the HttpApplicationState object is first locked
(which insures exclusive use) and then unlocked after the application is
added. */
myApp = new
ApplicationFeedback(app.MapPath("/mySite/data/settings.xml").ToLower());
app.Lock();
app.Add("ApplicationFeedbackKey", myApp);
app.UnLock();
}
return myApp;
}
}
|
Conclusion
With this custom Application class now defined, the ASPX
pages in the site will be able to access global site information by
using the static "Current" property. Additionally, the location
within the HttpApplicationState collection is completely managed from
within the object. This greatly simplifies the code that is
needed in the ASPX page itself. Please email any comments
regarding this tutorial to Will Hilley at
whilley@ase.tufts.edu. Enjoy!!!
|
|
 |
Web Services
|
|