Reference Application("") vars?

  • Thread starter Thread starter Keith Chadwick
  • Start date Start date
K

Keith Chadwick

I am having some trouble referencing an Application("myVar") variable from within a module.vb file on my ASP.NET site.

According to the documentation I should be able to reference System.Web.HttpApplication but it does not seem to like that one bit.
I also have a MSXML2.DOMDocument30 defined as a public object within the vb module which is loaded during the application start up with a bunch of XML. What is weird is that the data contained within the XML object seems to remain as an application level even though it is not defined as an application variable. The xml is stored within an application("myxml") variable but the object is not defined as an application level variable. In the old ASP module we where not supposed to declare objects within an Application variable so I am not in .NET.

I am coming from the old ASP module so I know I am thinking far to linear at this point but am I to understand that an object/var declared as public within a module.vb means its scope is application? If so, huh!

Thanks in advance

Keith
 
Okay, first, the Application Collection is there for backwards
compatibility, so you shouldn't be using it, as it isn't thread-safe. You
should be using the Application Cache instead. The Cache is thread-safe, and
objects stored there can be expired according to whatever rules you specify.

Second, forget the rules for ASP. EVERYTHING in .Net is an object, so store
anything you want in the Cache (except for database Connections, which
should be destroyed ASAP).

Third, to reference the Application Cache, you would have to refer to it in
context. For example, if you are writing code inside a Page class
definition, you can refer to "Cache" directly, as the Application Cache is
the "Cache" property of the Page class. If you're writing a utility class of
some sort, you need to grab the Cache from the current HttpContext, as in:
HttpContext.Current.Cache.

Finally, it might be best to forget about Modules. Although you can
certainly build Modules in .Net, they are also more for backwards
compatibility. A Module is basically a collection of Shared (static) data
and Methods, not very object-oriented. Instead, try to get used to
developing Classes and Class Libraries. You can create static (Shared)
properties and methods within a Class, but you will more often be working
with instantiated Classes. Shared/static methods and properties are more
problematic, and less likely to be necessary than instantiated Classes. A
Shared/static property is, in a sense, global, in that it is globally
accessible, but you don't have the control over accessibility that you have
with an instantiated Class property. For example, if a property is a public
property of an instantiated Class, you can have more than one instance of
it, whereas a static/Shared property exists in one and only one place. You
might say that a shared property of a module has Application scope, but it
is not the same thing as storing an object in the Application or Application
Cache. It actually exists in the heap, and, again, in one and only one
place.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Big Things are made up of
Lots of Little Things.


I am having some trouble referencing an Application("myVar") variable from
within a module.vb file on my ASP.NET site.

According to the documentation I should be able to reference
System.Web.HttpApplication but it does not seem to like that one bit.
I also have a MSXML2.DOMDocument30 defined as a public object within the vb
module which is loaded during the application start up with a bunch of XML.
What is weird is that the data contained within the XML object seems to
remain as an application level even though it is not defined as an
application variable. The xml is stored within an application("myxml")
variable but the object is not defined as an application level variable. In
the old ASP module we where not supposed to declare objects within an
Application variable so I am not in .NET.

I am coming from the old ASP module so I know I am thinking far to linear at
this point but am I to understand that an object/var declared as public
within a module.vb means its scope is application? If so, huh!

Thanks in advance

Keith
 
Ok, so what you are saying is application("") scope is now maintained via
application cache. This would be a good place to store things like my
connection string and some small XML blobs used commonly through all the
pages. How is the cache on storing objects, like a MSXML or a chunk of
transformed html?

Ok, so no modules, classes only. I can see that as modules are procedural.
I come from an ASP/VB background so to me it made sense to move my common
functions into a module for reuse by each page.

It is interesting that both the reference books I have, one from Microsoft
Press, cover application variables as if they belong and should be used.
There is only a brief mention that they are there for backwards
compatibility and no mention that you should use the cache instead. Perhaps
when starting a web project it would be nice if the UI asked you if you
wanted backwards compatibility and if not would remove those options.

One question about my SQL Server connections. You mentioned destroying them
ASAP but you would not want to have to open a connection several times on a
page load as that would not make sense, correct?

Is there a page on MSDN that provides a VISUAL MODEL of the .NET framework?
Pictures speak a thousand words!

Thanks for the info.

Cheers
Keith
 
Hi Keith,
pages. How is the cache on storing objects, like a MSXML or a chunk of
transformed html?
Click to expand...

In .Net, everything is an object. So, hopefully that clears that question
up!
It is interesting that both the reference books I have, one from Microsoft
Press, cover application variables as if they belong and should be used.
There is only a brief mention that they are there for backwards
compatibility and no mention that you should use the cache instead.
Click to expand...

Books are written by people. Heck, I've co-authored a couple of them. .Net
is new technology, and some of the people who write books are working with
brand new technologies, such as the books that were written about .Net
before it was released fully. In any case, the best authority on .Net is the
..Net SDK, which is a free download from:

http://www.microsoft.com/downloads/...A6-3647-4070-9F41-A333C6B9181D&displaylang=en
One question about my SQL Server connections. You mentioned destroying them
ASAP but you would not want to have to open a connection several times on a
page load as that would not make sense, correct?
Click to expand...

..Net uses Connection Pooling, and it is safer to destroy Connections each
time you use them. There are, of course, cases such as the one you mention,
in which it might be just as well to re-use the same Connection. On the
other hand, if you're using DataReaders, for example, this can be tricky, as
DataReaders cannot share a Connection. So, the short and simple answer is,
always close and re-open your Connections as quickly as possible. The long
answer is more difficult to define, and at this point in your .Net
education, probably not worth bothering with, as Connection Pooling makes
re-using Connections transparent to you, the developer.
Is there a page on MSDN that provides a VISUAL MODEL of the .NET framework?
Pictures speak a thousand words!
Click to expand...

Agreed. I think you'll find plenty of that sort of thing in the .Net SDK,
the most awesome software documentation ever written.

Best of luck to you in your endeavors, Keith.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Big Things are made up of
Lots of Little Things.
 
I must admit I understand what and where .NET is going in theory when I read
the books and online documentation. Having said that though, it is very
frustrating getting to know the .NET object model as it is so immense. It
is extra annoying considering I having been writing VB, ASP, XML, XSL and
SQL server for as long as I can remember and rip out code very quickly. Now
I find myself faced with getting frustrated with the model/syntax. Lucky
for me I am just sitting on the bench at the moment slogging through all of
this so I have the time to pull all my hairs out.

Cheers
Keith
 
Back
Top