I have two databases :
– a development database (for testing & dev)
– a production database (used by the latest release)
I can successfully interface with my DEV database to Linq using the VS2010 designer (drag and drop of tables that I am interested in and the rest gets generated). This creates me a dev.dbml, and from that, I can instantiate the class deriving from DataContext which gives me beautiful strongly-typed Linq capacity at no cost, which will reflect changes in the database for static code writing.
My program is an .exe which takes a string argument : “dev” or “prod”. Respectively, I’d like to use transparently the “dev” or the “prod” database without losing the strong typing and auto generation benefits of Linq. More importantly, the code has to be database-generic.
-
Maybe one solution would be to somehow use the settings declared in dev.dbml, but introduce flexibilty on the data source. I understand that this could introduce fails in “prod” (i.e. a table that exists in “dev” doesn’t in “prod”) but I will take care of the replication of “dev” structure to “prod” each time I release.
-
Another solution I was digging into was writing a wrapper for DataContext, but that would force me to duplicate manually entities from the databases into code… example here : http://andrewtokeley.net/archive/2008/07/06/mocking-linq-to-sql-datacontext.aspx
-
The other solution I would see would be to have dev.dbml and prod.dbml mapping to their respective databases, but then, how to offer generic code possibilities ?
How would you hack around this ?
LINQ-to-SQL stores its connection string in the application configuration file, which is what’s used by the default constructor. It should provide a constructor that allows you to pass in your own connection string. Just use that to pass in the connection string at runtime to whichever database you want to connect to.
This does, of course, require that whatever database you connect to has the same tables, columns, etc. as what you designed against.