Advice on the best place to store the connection information

[mit99mh]

I'm pretty new to ASP.NET and was wondering where is the best place to store the connection information. Should I create it in the Global.asax as an application variable or create connections when required using eg information from the web.config file?

Any help much appreciated

 

[gagz]

I put mine in web.config:

<appSettings>
    <add key=&quot;db_Conn&quot; value=&quot;server=(local);database=Northwind;user id=sa&quot;/>
</appSettings>

then use it like:

MyConnection = New SqlConnection(ConfigurationSettings.AppSettings("db_Conn"))

hth

 

[mit99mh]

Thanks for replying,

that's the method I was using but I wondered if creating the connection in Global.asax as an application variable had any advantages.

 

[link9]

No, but it has a disadvantage:

More memory allocated to the application

The answer to getting answered -- faq855-2992

 

[jfrost10]

I've also read that storing things like that within application variables is a BAD idea security wise.

D

 

[James1981]

It's gotta be stored somewhere right? If someone can get access to your connection string in your application variables then they are going to be able to get access to it anywhere.

James

 

[Craig0201]

Encrypt it using System.Security.Cryptography.DESCryptoSreviceProvider to avoid seucirty problems.

Craig

 

[jfrost10]

The best place really would be in the web.config file though.

Alternately, you could hardcode it inside a module or class within your project. But if it changes, then you have to change the code, recompile, etc. etc.

Mind you, if you put it inside the global.asax, you'd have to do that as well.

D'Arcy

 

[chiph]

There's also the Windows Registry.

Chip H.

 

[jfrost10]

Another thought I had: don't include the connection string anywhere within the project at all.

Instead, create a seperate data access tier object that holds all the connnection info, and just have your asp.net app call that object whenever it needs to get connected.

Of course, you still have the same issues about hardcoding the connection string within code. However though, this is more along an OO attitude where the presentation layer doesn't really need to know how to connect to the database, just what objects to use.

D'Arcy