Skip to content

Conversation

phusband
Copy link

@phusband phusband commented May 22, 2018

A few quick edits I made to the ProcessorLibrary which may be personal preference more than best-practices, but I think they do highlight an approach that can be useful in some cases.

DbProviderFactories is a nice to have for avoiding concrete classes like SqlConnection/SqlCommand/etc. hard-coded into the project. As long as the providers are configured somewhere in the chain of machine.config -> app.config/web.config, adding multiple connectionstrings with varying providers can require zero code changes as long as the System.Data.Common pattern has been implemented correctly (which in some cases requires some massaging behind the scenes, but the major providers are covered).

Also with the connectionKey as an appSetting, the idea would be to have multiple named connections that can be swapped out as desired:

<appSettings>
  <add key="DbConnectionToUse" value="Db_Prod"/>
  <add key="DefaultProvider" value="System.Data.SqlClient"/>
</appSettings>
<connectionStrings>
  <add name="Db_Prod" connectionString="Data Source=Production;Initial Catalog=Db;User ID=tcorey;Password=example" providerName="System.Data.SqlClient" />
  <add name="Db_Dev" connectionString="Data Source=Development;Initial Catalog=Db;User ID=tcorey;Password=example" providerName="System.Data.SqlClient" />  
</connectionStrings>

So any code keyed to use 'DbConnectionToUse' will use whichever connection the setting is pointed to.

Updated DataAccess to be database agnostic.
@TimCorey
Copy link
Owner

Thanks for the submission. I'll try to review it soon (sorry, pretty backlogged right now). The one initial thought I have is that I wouldn't put a production connection string in a config. Two issues with that. First, it exposes public credentials to developers. Second, it means that production code runs a bit differently than development code. This change, however minor, means that the application doesn't get tested fully. Instead what I do is replace the connection string on build with the appropriate one depending on location. That way the connection string itself changes but how you call it and what you call stays the same.

I'll review this and get back to you with my full thoughts soon. Thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants