How to manage connections when using DbModelBuilder in Entity Framework?

Question

I am writing an IRepository and IUnitOfWork wrapper for an EF4 Fluent schema.

In this design, a DbCompiledModel is created once per application lifecycle (Like an NHibernate ISessionFactory). The DbCompiledModel expects an existing database connection, as do all DbContexts.

This is the DbCompiledModel factory:

public class DbCompiledModelFactory
{
    public static DbCompiledModel Build(
        string mappingAssembly, DbConnection connection)
    {
        DbModelBuilder modelBuilder = new DbModelBuilder();
        AddMappingsFromAssembly(modelBuilder, mappingAssemblyName);
        DbModel model = modelBuilder.Build(connection);
        return model.Compile();
    }
}

Once the DbCompiledModel is created, a new DbContext can be created using new DbContext(connection, compiledModel, true)

So I am faced with two choices: Either share one DbConnection through the whole application lifecycle or create a shortlived DbConnection just for the model building process, and a new DbConnection whenever a DbContext is created.

Is there a more effective way of managing connections that I have overlooked?

EF caches the `DbCompiledModel` per app domin. Why do you want to duplicate that functionality? — Eranga, Nov 20 '11 at 01:08
I'd like to have the repository / unitofwork layer on top of EF because I may want to replace EF with another ORM at a later date. — duck9, Nov 20 '11 at 01:17
you didn't answer my question. ORM replacement/switching would be a very difficult. You are wasting time on unnecessary abstractions. — Eranga, Nov 20 '11 at 01:34
To rephrase: I want to duplicate that functionality because it will make it easy to replace the ORM implementation. — duck9, Nov 20 '11 at 01:47

score 0 · Answer 1 · answered Nov 20 '11 at 11:00

The connection itself is only needed to identify ADO.NET provider and manifest token. The Build method has overloaded version accepting DbProviderInfo instance. This overload is internally called by the overload accepting DbConnection. So you can call the version with DbProviderInfo directly if you don't like the one with DbConnection.

Don't use EF if you know that you will need another ORM later. Designing application to support multiple ORMs is only possible if you know uppfront all of them and design your application in the way that it uses only shared features among them. IMHO support more then one ORM is never needed and replacing ORM always means changes to application.

How to manage connections when using DbModelBuilder in Entity Framework?

1 Answers1