Constants and the Web.Config

WebConfig is made for storing such constants but there
are other methods as well. You can create a Module in
VB.NET or a class with Static Members in C# and query
your DB at the onset and populate these fields there. In
one case you change Web.Config when you want to make
changes, in the other you change you DB fields. Since
ADO.NET is probably how you'll access the data, they are
both essentially as dynamic as the other one.

However, there is one advantage to using the DB vs. Web
Config ---- although technically you can do the same
either way. If you write a simple encrypt/decrypt method
for a class, you can store the data in your DB encrypted
and decrypt it before use. You can write a simple app
for administration purposes that takes plain text and
encrypts it in your DB. Then you app can always decrypt
those fields. You can techincally do the same with a
Web.Config file, but it's a hassle because writing
parameters to a DB is a little simpler than walking an
XML tree and storing the data there.

I have some examples of both if you are interested, let
me know.

Good Luck,

Bill
>-----Original Message-----
>In general what is the best way to store site
constants.
>I am currently storing the database connection in the
>web.config and I have some other constants that should
>always be available, such as siteadmin@domain.com, and
>SiteName. Should I store these in the web.config
also?
>Is there a scenario where I should store constants
>elsewhere?
>.
>