Better Alternative than Application State?

Better Alternative than Application State?

am 23.04.2008 21:50:14 von Peter Schwartz

In addition to Web.config, I have a few configuration values that I store in
a sql server database. I would like to read them from the database only once
per Application.Start (there is no need to read the values per session, as
the values are used throughout the entire application and are needed by many
pages).

Just wondering if Application state would be the best place to store these
values. Are there better alternatives for my scenario?

I don't think the Cache is a good alternative because items in it can get
removed unpredictably, and I need these values to hang around on a permanent
basis.

Your comments and thoughts are appreciated.

RE: Better Alternative than Application State?

am 24.04.2008 01:13:00 von mily242

Static member(s) will also be appropriate in this scenario. i.e.

public static class ConfigStuff
{
public static readonly int Value1;

static ConfigStuff()
{
// initialize static members with values from database
// ....
Value1 = 10;
}

}

--
Milosz


"Cramer" wrote:

> In addition to Web.config, I have a few configuration values that I store in
> a sql server database. I would like to read them from the database only once
> per Application.Start (there is no need to read the values per session, as
> the values are used throughout the entire application and are needed by many
> pages).
>
> Just wondering if Application state would be the best place to store these
> values. Are there better alternatives for my scenario?
>
> I don't think the Cache is a good alternative because items in it can get
> removed unpredictably, and I need these values to hang around on a permanent
> basis.
>
> Your comments and thoughts are appreciated.
>
>
>
>

RE: Better Alternative than Application State?

am 24.04.2008 18:47:01 von pbromberg

Your scenario is basically what Application state is for.
-- Peter
To be a success, arm yourself with the tools you need and learn how to use
them.

Site: http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://ittyurl.net


"Cramer" wrote:

> In addition to Web.config, I have a few configuration values that I store in
> a sql server database. I would like to read them from the database only once
> per Application.Start (there is no need to read the values per session, as
> the values are used throughout the entire application and are needed by many
> pages).
>
> Just wondering if Application state would be the best place to store these
> values. Are there better alternatives for my scenario?
>
> I don't think the Cache is a good alternative because items in it can get
> removed unpredictably, and I need these values to hang around on a permanent
> basis.
>
> Your comments and thoughts are appreciated.
>
>
>
>

Re: Better Alternative than Application State?

am 24.04.2008 19:04:49 von George Ter-Saakov

I always have a class with static varaibles in my applications for that
purpose....

Call it clsGlobal for example.

class clsGlobal
{
public static string _sConnection;
public static void Init()
{
_sConnection =
System.Configuration.ConfigurationSettings.AppSettings["Conn ectionString"];
}
public static string FormatMoney(decimal dTotal)
{
return dTotal.ToString("$0.00");
}
}

Application_Start(...)
{
clsGlobal.Init();
}

Then everywere in my application i use
clsGlobal._sConnection
or something like
<%#clsGlobal.FormatMoney(Eval("OrderTotal"))%>


Hope you get an idea....
George.


"Peter Bromberg [C# MVP]" wrote in message
news:1C99C42C-D21F-42E4-8E24-BE34D858B056@microsoft.com...
> Your scenario is basically what Application state is for.
> -- Peter
> To be a success, arm yourself with the tools you need and learn how to use
> them.
>
> Site: http://www.eggheadcafe.com
> http://petesbloggerama.blogspot.com
> http://ittyurl.net
>
>
> "Cramer" wrote:
>
>> In addition to Web.config, I have a few configuration values that I store
>> in
>> a sql server database. I would like to read them from the database only
>> once
>> per Application.Start (there is no need to read the values per session,
>> as
>> the values are used throughout the entire application and are needed by
>> many
>> pages).
>>
>> Just wondering if Application state would be the best place to store
>> these
>> values. Are there better alternatives for my scenario?
>>
>> I don't think the Cache is a good alternative because items in it can get
>> removed unpredictably, and I need these values to hang around on a
>> permanent
>> basis.
>>
>> Your comments and thoughts are appreciated.
>>
>>
>>
>>

Re: Better Alternative than Application State?

am 24.04.2008 20:41:05 von mily242

Hi George,

Just a small suggesyion - no need for calling Init method from application
start. It enough to use a static constructor.
--
Milosz


"George Ter-Saakov" wrote:

> I always have a class with static varaibles in my applications for that
> purpose....
>
> Call it clsGlobal for example.
>
> class clsGlobal
> {
> public static string _sConnection;
> public static void Init()
> {
> _sConnection =
> System.Configuration.ConfigurationSettings.AppSettings["Conn ectionString"];
> }
> public static string FormatMoney(decimal dTotal)
> {
> return dTotal.ToString("$0.00");
> }
> }
>
> Application_Start(...)
> {
> clsGlobal.Init();
> }
>
> Then everywere in my application i use
> clsGlobal._sConnection
> or something like
> <%#clsGlobal.FormatMoney(Eval("OrderTotal"))%>
>
>
> Hope you get an idea....
> George.
>
>
> "Peter Bromberg [C# MVP]" wrote in message
> news:1C99C42C-D21F-42E4-8E24-BE34D858B056@microsoft.com...
> > Your scenario is basically what Application state is for.
> > -- Peter
> > To be a success, arm yourself with the tools you need and learn how to use
> > them.
> >
> > Site: http://www.eggheadcafe.com
> > http://petesbloggerama.blogspot.com
> > http://ittyurl.net
> >
> >
> > "Cramer" wrote:
> >
> >> In addition to Web.config, I have a few configuration values that I store
> >> in
> >> a sql server database. I would like to read them from the database only
> >> once
> >> per Application.Start (there is no need to read the values per session,
> >> as
> >> the values are used throughout the entire application and are needed by
> >> many
> >> pages).
> >>
> >> Just wondering if Application state would be the best place to store
> >> these
> >> values. Are there better alternatives for my scenario?
> >>
> >> I don't think the Cache is a good alternative because items in it can get
> >> removed unpredictably, and I need these values to hang around on a
> >> permanent
> >> basis.
> >>
> >> Your comments and thoughts are appreciated.
> >>
> >>
> >>
> >>
>
>
>

Re: Better Alternative than Application State?

am 24.04.2008 20:53:39 von George Ter-Saakov

I would say it's a novel idea (at least for me). But I would classify it as
dangerous. Have you actually tried to use it?
Here is an explanation:
Are you positive that .NET library is properly initialized at the point when
static constructor called?
I mean that your
System.Configuration.ConfigurationSettings.AppSettings["Conn ectionString"];
will actually work correctly.
I would imagine that when application is loaded into memory .NET must do a
lot of work before this line can be executed... Like load web.config for
example. Or even determine that it must be web.config and not
executablename.config...

And static constructor is executed first thing application is loaded into
memory and only then execution point is given to WinMain or whatever it is
in ASP.NET world.
------------------------------------------------------------ ------

I apologize, I hate to be the downer here.... But I would stick with calling
it in Application_Start. Nobody wants it's application suddenly stop working
(even if it does now) when you switch to new version of .NET


PS: I know those problems first hand when I worked on C++ (long time ago)
and application would blow up when i called printf in static constructor.

Thanks
George.

"Milosz Skalecki [MCAD]" wrote in message
news:4B58DCC7-DF28-4C14-8BC1-88DBC2887127@microsoft.com...
> Hi George,
>
> Just a small suggesyion - no need for calling Init method from application
> start. It enough to use a static constructor.
> --
> Milosz
>
>
> "George Ter-Saakov" wrote:
>
>> I always have a class with static varaibles in my applications for that
>> purpose....
>>
>> Call it clsGlobal for example.
>>
>> class clsGlobal
>> {
>> public static string _sConnection;
>> public static void Init()
>> {
>> _sConnection =
>> System.Configuration.ConfigurationSettings.AppSettings["Conn ectionString"];
>> }
>> public static string FormatMoney(decimal dTotal)
>> {
>> return dTotal.ToString("$0.00");
>> }
>> }
>>
>> Application_Start(...)
>> {
>> clsGlobal.Init();
>> }
>>
>> Then everywere in my application i use
>> clsGlobal._sConnection
>> or something like
>> <%#clsGlobal.FormatMoney(Eval("OrderTotal"))%>
>>
>>
>> Hope you get an idea....
>> George.
>>
>>
>> "Peter Bromberg [C# MVP]" wrote in
>> message
>> news:1C99C42C-D21F-42E4-8E24-BE34D858B056@microsoft.com...
>> > Your scenario is basically what Application state is for.
>> > -- Peter
>> > To be a success, arm yourself with the tools you need and learn how to
>> > use
>> > them.
>> >
>> > Site: http://www.eggheadcafe.com
>> > http://petesbloggerama.blogspot.com
>> > http://ittyurl.net
>> >
>> >
>> > "Cramer" wrote:
>> >
>> >> In addition to Web.config, I have a few configuration values that I
>> >> store
>> >> in
>> >> a sql server database. I would like to read them from the database
>> >> only
>> >> once
>> >> per Application.Start (there is no need to read the values per
>> >> session,
>> >> as
>> >> the values are used throughout the entire application and are needed
>> >> by
>> >> many
>> >> pages).
>> >>
>> >> Just wondering if Application state would be the best place to store
>> >> these
>> >> values. Are there better alternatives for my scenario?
>> >>
>> >> I don't think the Cache is a good alternative because items in it can
>> >> get
>> >> removed unpredictably, and I need these values to hang around on a
>> >> permanent
>> >> basis.
>> >>
>> >> Your comments and thoughts are appreciated.
>> >>
>> >>
>> >>
>> >>
>>
>>
>>