Place Connection String in Model or GUI

I have a VB.NET 2010 solution, that contains 2 projects, a class library and a Windows Forms Application.

The class library basically is a model, used for doing database integration.

I currently have the connection string placed in the class library project settings, but they do not seem to be listed anywhere 开发者_如何学Pythonin the config file of the application. What's the best practice for retrieving the connection string in the class library? I don't want to use a singleton. Should it be stored in the application or class library?

It seems the Class Library would make more sense since that is project interacting with the database. It would probably be beneficial to encrypt the connection string and store it in a file or registry key so that way if the system is compromised, the intruder will still have to crack the key to view the connection string, yet still offers you the ability to change it without recompiling your app.

I still go with what I said in your earlier question - leave the settings/configurations out of the class library. Put them in the config file for the application(s) that use the class library.

What happens if the connection string changes? Since class library's don't use config files, you'll most likely have to update the code, recompile, and redeploy it. Not a big deal if it's one program on one machine, but what if it's multiple programs and/or multiple machines?

Granted, you'd still have to make a lot of changes in a multi-program/multi-system environment via the config file, but that's a lot simpler, IMO, than recompiling (and regression testing) a class library.

Another factor to consider is what if different applications want to use this same class library? What if you have different environments that have different connection strings? And so on.

In a nutshell, I would opt to leave configuration items for the application, not the supporting class libraries. From a resusability and scalability perspective I feel that gives you the most bang for your buck.

If you only have one application and its only ever going to use this one class library, and no one else will, you can probably leave the configuration settings in it - but using the phrase "We'll never change" or "It will always be like this" is a good way to get a lot of headaches down the road.

All of the above is, of course, in my opinion, and should not be taken as me speaking officially for any other programmer or corporation :)

Edited to add

You'll have to manually move the settings you need from the class library's config to the application's config. VS won't do it for you.

And why do you keep bringing up the singleton design pattern? What potential benefit do you see from it? Or have other people been suggesting it to you?