Strategies for the caller to decide data connection

Question

Consider an existing data access and business logic layer that is used by multiple different applications and that, until now, only needed a single data connection for the lifetime of any given application that consumed it - so the connection info could simply be pulled by the data layer from the application's config file. Moving forward, however, the data and logic classes need to provide the flexibility for the applications to determine the data connection on a per call basis. What's more, the classes are now called by multiple applications simoultaneously through services.

The callers don't want to manage connection strings specifically, but rather connection names in the form of an enum that can be resolved to connection strings in and by the data layer.

Currently, all data and logic classes are static with the data being scoped internal and the logic being scoped public.

What are some good strategies to get a key from the caller all the way down to the methods in the data classes considering things like API useability, performance, thread safety / caller isolation, etc.

Two obvious options are:

1. Add the connection key as a parameter to all methods. Yuck - isn't going to happen but including for completeness.

2. Change the logic and data classes to instance classes and pass the key in the constructors for any member method to use. There would be no method signature changes but a substantially breaking change to how the API is called.

What other options are there?

Answer 1

Unfortunately, you hit the two best options for how to deal with this type of issue. #2 is made a bit more complicated by having services involved, because different service requests are either going to need a way to remember which client is which (like sessions) or going to have to pass the connection information through the service on each call.

I think if you create a client side wrapper class to access the service, you can limit how many client side changes you're going to need. For the service itself, I think you're really going to be stuck passing the connection as a parameter each time simply because the alternatives there are pretty complicated.