Database connection strings used to be simple. Well, simple, once you learned the arcane syntax. But, at least they had stayed the same for about a decade. But with the EntityFramework, they took on an even more arcane “connection string – within –a –connection string” format. And while the inner connection string related to your database, the wrapping connection string was intimately tied to the entity context.
So, in that past, one App.config connect string entry was good for all your DB needs for one database. Now, if you have several different EF contexts, all referring to tables in the same physical database, you need to have several connection strings, with the outer string different and the inner part the same --- until you need to connect to a different database, then you leave the existing outer strings and change all the inner strings in parallel. This really seems to me to be a design flaw on Microsoft’s part, but let’s see if we can work something to make it easier. We’d really like to have one connection string for all our EF needs.
If you’re using more than one EF context, you’re probably using one for most things – your core business objects – and others for more cross-project, framework needs (auditing, logging, etc.). So, let’s say you have one connection string set up for the main context, then all we need do is write a method which takes one EF context, extracts the database connection information, and uses that to build a new EF context.
And the Entity Framework meets us halfway, providing the
EntityConnectionStringBuilder class. We just create an
EntityConnectionStringBuilder object, set three properties, and boom—we have our new connection string. And one of those properties (
Provider) is pretty much fixed (usually, "
System.Data.SqlClient", but even if it’s for a different vender, you’ll probably be standardized on one database vendor). The second (
Metadata) is basically fixed for the context (I assume there’s sometime a need to vary that, but I haven’t seen one). That just leaves
ProviderConnectionString, which is where things get tricky.
EntityContext object does contain the needed connection
string, it’s buried three levels down, in a property not exposed by the
IDbConnection interface that we are given. We have to cast a property to an
EntityConnection object to be able to access it.
Putting all that together, here’s the code:
1: public SecondEFContext(FirstEFContext context1)
3: var eb = new EntityConnectionStringBuilder();
4: eb.Provider = "System.Data.SqlClient";
5: var context1Conn = context1.Connection as EntityConnection;
6: eb.ProviderConnectionString = context1Conn.StoreConnection.ConnectionString;
7: eb.Metadata = @"res://*/SecondEF.csdl|res://*/SecondEF.ssdl|res://*/SecondEF.msl";
9: var entC = new EntityConnection(eb.ToString());
11: return new SecondEFContext(entC);
Share this post: Email it! | bookmark it! | digg it! | reddit!