title: Strategies for the caller to decide data connection
body: <p>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.</p>
  
  <p>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.</p>
  
  <p>Currently, all data and logic classes are static with the data being scoped internal and the logic being scoped public.</p>
  
  <p>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.</p>
  
  <p>Two obvious options are:</p>
  
  <ol>
  <li><p>Add the connection key as a parameter to all methods. Yuck - isn't going to happen but including for completeness.</p></li>
  <li><p>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.</p></li>
  </ol>
  
  <p>What other options are there?</p>