Reference Application("") vars?

Discussion in 'ASP .Net' started by Keith Chadwick, Nov 4, 2003.

  1. 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
     
    Keith Chadwick, Nov 4, 2003
    #1
    1. Advertising

  2. 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.


    "Keith Chadwick" <> wrote in message
    news:...
    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
     
    Kevin Spencer, Nov 4, 2003
    #2
    1. Advertising

  3. 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


    "Kevin Spencer" <> wrote in message
    news:...
    > 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.
    >
     
    Keith Chadwick, Nov 4, 2003
    #3
  4. Hi Keith,

    > pages. How is the cache on storing objects, like a MSXML or a chunk of
    > transformed html?


    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.


    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?


    ..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!


    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.

    "Keith Chadwick" <> wrote in message
    news:...
    > 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
    >
    >
    > "Kevin Spencer" <> wrote in message
    > news:...
    > > 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.
    > >

    >
    >
     
    Kevin Spencer, Nov 4, 2003
    #4
  5. 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


    "Kevin Spencer" <> wrote in message
    news:...
    > Hi Keith,
    >
    > > pages. How is the cache on storing objects, like a MSXML or a chunk of
    > > transformed html?

    >
    > 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.

    >
    > 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?

    >
    > .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!

    >
    > 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.
    >
    > "Keith Chadwick" <> wrote in message
    > news:...
    > > 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
    > >
    > >
    > > "Kevin Spencer" <> wrote in message
    > > news:...
    > > > 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.
    > > >

    > >
    > >

    >
    >
     
    Keith Chadwick, Nov 5, 2003
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike Laskie
    Replies:
    1
    Views:
    1,574
    Carl Prothman [MVP]
    Aug 21, 2003
  2. Jon

    app vars and cache vars

    Jon, Dec 14, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    399
  3. Linuxguy123
    Replies:
    7
    Views:
    698
    Paddy O'Loughlin
    Feb 20, 2009
  4. caccolangrifata
    Replies:
    18
    Views:
    399
    Chris Torek
    Jul 22, 2011
  5. Greg Willits

    Dynamically reference instance vars

    Greg Willits, Oct 30, 2010, in forum: Ruby
    Replies:
    10
    Views:
    220
    Robert Klemme
    Oct 31, 2010
Loading...

Share This Page