Least-bad way to change constructor behaviour

Question

I feel like I'm stuck between several bad solutions here and need some advice on how to minimize future agony. We are using Massive ORM, which in its constructor has these lines:

var _providerName = "System.Data.SqlClient";

if (ConfigurationManager.ConnectionStrings[connectionStringName].ProviderName != null)
    _providerName = ConfigurationManager.ConnectionStrings[connectionStringName].ProviderName;

_factory = DbProviderFactories.GetFactory(_providerName);
ConnectionString = ConfigurationManager.ConnectionStrings[connectionStringName].ConnectionString;

The important part for me here is that it reads the connection strings from ConfigurationManager. We are trying to centralize configuration, and in doing this we want to keep connection strings out of our web/app.configs (we have somewhere around 150 deployed hosts, so the overhead is becoming significant). However, this breaks down since the config file read is hardcoded here, and the ConnectionStrings collection is read only (there are workarounds, but they are all quite dirty).

One possible way out of this is to extract these lines into a virtual method and then change it with inheritance. This is not so nice when we want to update Massive though, and also calling virtual methods from a constructor is potentially bad.

What other alternatives do I have? Main priority here is to minimize impact when updating.

Answer 1

In the end, we decided to make a minimal change to the massive class by making it partial. Then in a separate file, we added an additional constructor which accepted different parameters. This way, if we update the library, the only change we need to make is adding the partial again.

Answer 2

You can eliminate the object's configuration source dependency by passing in all required fields through the constructor.

See Martin Fowler's article on Dependency Injection. The same concept applies here.