Reputation: 331
I've seen quite a few posts about this but I don't understand how to implement this.
My connection string is specified as "MealsContext" in app.config, My EF datamodel container name is "MealsContext", how can I use an instance of MealsContext but define the connection string to be used at runtime? If I create a new EntityConnection it doesn't know what entity objects are in the model, e.g. this is what I'm currently doing...
private MealsContext context = new MealsContext();
public void InsertOrUpdate(Meal _entity)
{
context.Entry(_entity).State = _entity.Id == default(int) ? EntityState.Added : EntityState.Modified;
context.SaveChanges();
}
Upvotes: 3
Views: 4267
Reputation: 154
EF 6's base class for database contexts,DbContext
, has a couple of overloads - one of which takes a DbConnection
and a Boolean flag indicating if the previously mentioned DbConnection
object should be disposed of when the context is disposed (IOW if true, the DbConnection
is disposed when the context is disposed). you could also use the constructor overload that simply takes a connection string, but I wanted to throw in an example showing how to do this while controlling the life time of the DbConnection
object.
the snag is that when your specific context is generated, by default only the default (public/parameterless) constructor is made available, which if you look at the generated class, alludes to using a config file based EF connection string entry. the good thing is that your generated context that inherits from the DbContext
follows the best practice of generating your context class with the partial modifier, which allows you create your own partial
implementation of your specific model's context.
I would recommend creating a new class file (explicitly NOT the code generated file) in your project and, at a minimum, make a partial
implementation of your model's context class with just a constructor that has a DbConnection
and a bool
argument to mirror the aforementioned DbContext
constructor signature.
for example, if the generated context is defined as:
public partial class MyModelContainer : DbContext...
then you can create your partial class implementation (in your shiny, new, and separate class file of course):
public partial class MyModelContainer
{
public MyModelContainer(DbConnection dbConnection, bool contextOwnsConnection)
: base(dbConnection, contextOwnsConnection)
{
// you can other stuff here if you need to, but don't have to for this example
}
}
if you've gotten this far, you should be able to create MyModelContainer
objects with database connections as dynamic as the connection strings used by the DbConnection
object you provide.
example:
public void DynamicConnectionExample(string entityConnectionString)
{
DbConnection dbConnection = new EntityConnection(entityConnectionString);
bool shouldImplicitlyDisposeOfConnection = true;
using (var ctx = new MyModelContext(dbConnection, shouldImplicitlyDisposeOfConnection))
{
// do stuff...
}
}
obviously, you could get a little creative with ways to configure the DbConnection object's connection string and I would recommend exploring ways of doing so other than the way shown in the example.
Also worth noting: depending on whether you're using model-first or code-first the would have an impact on the specialized type of DbConnection
you would be using. for instance, you would use an EntityConnection
object if you're using an EF model because of the required access to metadata compiled resources in your assembly.
ref: http://msdn.microsoft.com/en-us/library/gg696604(v=vs.113).aspx
Upvotes: 1
Reputation: 331
Just in case anyone else is looking for this, I cobbled the answer together from a few other posts which say the same thing but I didn't get it at first. I added several different named connection strings in the app.config file. Then I overrode the context class which is in the entity model so that it takes the name of the connection string as a parameter
public MealsContext(string connectionString) : base(connectionString)
{
}
The string that I passed in is "name=csTest", where csTest is a connection string defined in the app.config. The trick though, is to specify this context somewhere separately - e.g. in a class library folder, so that the context doesn't get overwritten automatically when the model is updated or rebuilt.
Upvotes: 1