问题
I'm building an application that accesses various databases. Currently the connection strings are stored in the App.Config file. However I'd like to be able to configure the connection strings for the database more easily.
I'm considering having a single "master" database that contains the connection strings for all the other databases. This would mean that each application that requires a database connection would lookup the connection from the master database.
The App.config file could store the table name for the database connection strings. This would allow for multiple instances of the application to use the same "master" database with a different table for looking up the connection strings.
What are the advantages/disadvantages of this approach?
Has anyone done something similar?
Is this considered a best practice?
回答1:
If you are looking for a centralised configuration service then look no further that the StockTrader.Net sample app which includes a complete config service with source.
回答2:
I don't know about Best Practice, however this is a very common pattern.
You often see the pattern of a treeview on the left side of an app where you create "connections", you then expand these connection widgets to show views / tables / stored procs etc. And of course these connections are saved along with their connection strings. (either to a database or a local config file)
Some Examples are MS SQL Server management tool, Quest's Toad Suite of products etc etc. Its very common indeed.
来源：https://stackoverflow.com/questions/4281463/centralised-database-connection-string-provider