Data Access classes are a common strategy. Although they are usually in their own layer, and designed to
be stateless. Throwing this on top of MS application block for sql data is a good idea too. This is part and parcel with standard
n-tier methodology.
 
Objects in the session store do not travel back and forth to the client. They would only have to travel back and forth to a session
state server or session state sql server.
 
Storing objects in application state could lead to some performance problems. I have rarely run into a situation where doing so is
the best solution.
 
Brian
 
 

	-----Original Message----- 
	From: Andrew Hanscom [mailto:andrew.hanscom@p...] 
	Sent: Fri 2/7/2003 1:37 PM 
	To: ASPX_Professional 
	Cc: 
	Subject: [aspx_professional] Application objects - good idea?
	
	

	I would like some feedback on the following:
	
	I have created an object that is responsible for data retrieval.  On
	Application_Start I tuck an instance of it away as an Application
	variable.  The aspx.vb code-behind pages, when they need some data,
	utilize its methods like so:
	
	dgPorts.DataSource = Application("DataMiner").GetPorts
	
	I see the pros of this approach as such:
	1) I don't have data access code all over the place
	2) It is not in the session, so it's not traveling back and forth to/from
	the server
	3) Easy maintenance
	
	What about the cons?
	1) What impact does this have on the overall performance of the
	Application?
	2) Are there contention problems - if I have 100 people hammering away at
	the same time?
	3) What other things should I be considering?
	
	Thanks in advance for your input.
	
	Drew