1

EF4 Fluent スキーマのラッパーを作成していIRepositoryます。IUnitOfWork

この設計では、DbCompiledModelはアプリケーションのライフサイクルごとに 1 回作成されます (NHibernate のようにISessionFactory)。は、すべてのDbCompiledModel場合と同様に、既存のデータベース接続を想定していますDbContexts。

これはDbCompiledModel工場です：

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();
    }
}

がDbCompiledModel作成されると、新しいDbContextを使用して作成できます。new DbContext(connection, compiledModel, true)

そのため、私は 2 つの選択肢に直面してDbConnectionいます。アプリケーションのライフサイクル全体で 1 つを共有するかDbConnection、モデル構築プロセスのためだけに存続期間の短いものを作成し、 DbConnectiona が作成されるたびに新しいDbContextものを作成します。

私が見落としていた接続を管理するためのより効果的な方法はありますか?

4

1 に答える 1

0

接続自体は、ADO.NET プロバイダーとマニフェスト トークンを識別するためにのみ必要です。メソッドは、インスタンスBuildを受け入れるバージョンをオーバーロードしています。DbProviderInfoこのオーバーロードは、オーバーロードを受け入れることによって内部的に呼び出されDbConnectionます。したがって、 のバージョンDbProviderInfoが気に入らない場合は、 のバージョンを直接呼び出すことができますDbConnection。

後で別の ORM が必要になることがわかっている場合は、EF を使用しないでください。複数の ORM をサポートするアプリケーションの設計は、すべての ORM を事前に把握し、それらの間で共有される機能のみを使用するようにアプリケーションを設計する場合にのみ可能です。IMHO サポートの複数の ORM は必要なく、ORM の置き換えは常にアプリケーションの変更を意味します。

于 2011-11-20T11:00:22.907 に答える