Reusable Components, database connections and different environments

Question

I am wondering what would be considered best practice when setting up reusable components / libraries in .net. I have a webservice that utilizes a library that contains a few database connection for interacting with databases. I am wondering how I should set my library up when it comes to specifying the connection strings.

I need to be able to alter to which database the reusable component connects to as I am deploying to dev/uat/prod environments. Also there is a certain need to being able to trace who is doing database calls -- I might want to see who is the user of the reusable component so if webservices A and B are each using it I might want ws_A_usr to be used in the connection string and likewise for B.

I see a few ways this could be done but I as I am refactoring some legacy all three implementations are being used.

Should I read connectionstrings from config (MyLib.Properties.Settings.Default.abcConnectionString)

Should I accept connectionstrings as parameters in my api?

Should I accept IDbConnection as parameters in my api?

Are there other more suitable ways to do this - what would be the best one?

Answer 1

I would say that the library should be independent of it's user (in this case the webservice). In that respect, having a dependency on a config file is not so nice.

You do want the connectionstring in the web.config of your webservice, but you want to pass it to the library through a parameter at some point. This would allow you to use the same library in a non web project. Also it would allow you to implement different ways to get the connectionstring (from a webservice call, perhaps).

HTH. Jonathan

Answer 2

To my mind, this depends on how tightly bound to the component the connections are. If the connections are to a database that will only be used by the component, then it doesn't make sense to force the users of the component to know anything about those connections. In that case, keeping the connection strings in a configuration file works (app.config or web.config). In fact, it might be adequate to keep the connection strings internal to the component, but to expose the database server name in the config file.

If the component is using the same database as the users of the component, then permit the connection to be passed in as a property of the component. The component could the choose whether to default to a built-in connection string if the property is not set, or to throw an exception if the property is not set.

---

If you don't mind exposing the entire connection string to the consumers, then allow the entire string to live in app.config or web.config. In particular, use the .NET 2.0 Application Settings feature (Properties\settings.settings). This will cause defaults to be compiled into the assembly, yet when the component is consumed, these defaults will get written into the app.config file. They may be edited from there.

If you want to limit the parts of the connection string that can be changed, then compile those parts into the assembly. Expose individual properties for the parts you'll allow to change. In particular, expose database server name, application name, username, password, etc. These properties would set the corresponding parts of the connection string. See the SqlConnectionStringBuilder class if you didn't already know about it.