This project has moved and is read-only. For the latest updates, please go here.

Using Effort by init the DB with a connectionString

May 30, 2013 at 9:02 PM
Edited May 30, 2013 at 9:02 PM
I have been playing around with Effort trying to get it to work with the code we currently have with minimal changes. The problem is that all of our DBContext classes are created with a ConnectionString. I'm not sure how I can set this up so that the EffortDb is used if a particular connectionString is passed in. If I passed in a DbConnection created with the "Effort.DbConnectionFactory" I can get it working. So close... but yet so far.

Any help would be great! :)
May 30, 2013 at 10:31 PM
Edited May 30, 2013 at 10:41 PM

Where are the connection strings coming from and how are the DbContext objects instantiated?

I do not particularly recommend the direct usage of connection strings because it is quite inflexible. In my opinion it is a better approach is to have some kind of factory (static or injected) for the DbContext or DbConnection objects. For example:

I assume that your code looks like this:
var context = new CustomDbContext("name=connstring");
It can be easily changed to this (with find and replace):
var context = CustomDbContextFactory.Create();
This makes possible to centralize the way your DbContext is created. You can implement the factory to use a connection string, explicitly created DbConnection object or even the DbConnectionFactory of Effort. You can also make the factory in a way that it allows to change its inner working during run time. For example:
I prefer to use not static, but injectedfactories. You can read more about this and a complete design in one of my tutorials.

On the other hand I was thinking about how Effort could be utilized purely with connection strings. With persistent connections, I think it is possible:
  <add name="Effort" connectionString="InstanceId=instanceName" providerName="Effort.Provider" />
You should call this at the start of your application / test process:
In the moment creating transient fake databases is not possible in this way, but I put it on my TODO list.