Design Meeting Notes - March 14, 2013

File/code-based configuration precedence

EF-wide configuration can be done in app.config/web.config or in code using DbConfiguration. Currently any configuration done in a configuration file will take precedence over configuration done in code. This is so that configuration can potentially be used for tracing/debugging of an existing application without needing to recompile the application, which may not be possible at the time that tracing/debugging needs to happen.

The problem with this is that if some settings exist in a config file and then a DbConfiguration is created and settings are added to it, then the settings in the config file will still be used over the new settings that have been made in code. This can be confusing especially if the developer does not know that the config file contains any settings, which is often the case for the default connection factory since this is set in the config file automatically when EF is installed.

Options discussed:

  • Make no change to behavior, but add documentation, especially to Intellisense for SetDefaultConnectionFactory, to help with the confusion.
  • Warn if a setting in the config file is also set in DbConfiguration.
    • The problem with this is that there is no real way of warning at runtime and throwing would prevent the config file from being changed without rebuilding anyway.
  • Switch to make code-based configuration take precedence over config file based configuration.
    • This means that making a setting in DbConfiguration will always work even if the setting is in the config file already.
    • Changing configuration without rebuilding will only work if the developer chooses to use config files.
      • This requires the developer to have forward knowledge of what may happen with the app and also to be aware that this is the way things work. It would seem likely that developers may not have this knowledge until too late.
  • Switch the precedence and add a flag to each DbConfiguration method to indicate that the config file should take precedence.
    • One problem here is that the developer still has to have forward knowledge that the flag needs to be set, even though it may be easier for the developer to discover that this is important before it is too late.
    • Also, this would result in flags in all DbConfiguration methods which isn’t very clean.
  • Leave the precedence as is, but add a flag to each DbConfiguration method to indicate that it should take precedence over the config file.
    • It’s unclear when a developer would set this flag. If he/she knows that there is a setting in the config file already, then why not remove it? If he/she doesn’t know, then the flag doesn’t make much sense, except possibly to help the developer discover the setting in the file such that they can then remove it.
    • Also, as with the previous option, this adds flags in a lot of places.
  • Switch the precedence and allow a flag (or flags) in the config file to allow config file settings to override code-based configuration.
    • This would probably work, but it adds more complexity to the mental model of which settings come from where such that it may cause more confusion than leaving the behavior as is. For example, the developer must understand that:
      • The setting can be made in the config file
      • The setting in the config file will not override the setting in code (may go against expectations)
      • This can be changed with a flag

Ultimately we decided that none of the options that change behavior are clearly better than leaving the behavior as is and adding documentation, etc., to help make people aware of it. One factor that played into this is that the only real source of confusion here seems to be setting the default connection factory, but this is something that may not be common for people to configure in real applications since it is only necessary when creating connection strings by convention to a local server.

We also discussed the idea of creating code-based configuration by default for new apps, but this discussion was deferred because we would still have to deal with the case of existing apps.<!--EndFragment-->

Last edited Mar 15, 2013 at 8:28 PM by ajcvickers, version 2