58

IDbContextEntity Framework にインターフェイスがないのはなぜですか? カスタム データベース コンテキスト インターフェイスを派生できる SaveChanges() などのメソッドを備えた既存のインターフェイスがあれば、テストするのは簡単ではないでしょうか?

public interface ICustomDbContext : IDbContext
{
    // add entity set properties to existing set of methods in IDbContext
    IDbSet<SomeEntity> SomeEntities { get; }
}
4

4 に答える 4

16

私はこれを見ますIDbContext

このリンクを参照してください次に、Entities Context With That インターフェイスの新しい部分クラスを作成します。

public partial class YourModelEntities : DbContext, IDbContext 

EDITED:私はこの投稿を編集しました.This Works for me. 私の状況

namespace dao
{
    public interface ContextI : IDisposable
    {
        DbSet<TEntity> Set<TEntity>() where TEntity : class;
        DbSet Set(Type entityType);
        int SaveChanges();
        IEnumerable<DbEntityValidationResult> GetValidationErrors();
        DbEntityEntry<TEntity> Entry<TEntity>(TEntity entity) where TEntity:class;
        DbEntityEntry Entry(object entity);
        string ConnectionString { get; set; }
        bool AutoDetectChangedEnabled { get; set; }
        void ExecuteSqlCommand(string p, params object[] o);
        void ExecuteSqlCommand(string p);
    }
}

YourModelEntities は自動生成された部分クラスであり、同じ名前で新しい部分クラスを作成し、新しいコンテキスト インターフェイスを追加する必要があります。この例では ContextI です。

注: メソッドは自動生成コードに実装されているため、インターフェイスはすべてのメソッドを実装していません。

namespace dao
{
    public partial class YourModelEntities :DbContext, ContextI
    {
        public string ConnectionString
        {
            get
            {
                return this.Database.Connection.ConnectionString;
            }
            set
            {
                this.Database.Connection.ConnectionString = value;
            }
        }

        bool AutoDetectChangedEnabled
        {
            get
            {
                return true;
            }
            set
            {
                throw new NotImplementedException();
            }
        }

        public void ExecuteSqlCommand(string p,params object[] os)
        {
            this.Database.ExecuteSqlCommand(p, os);
        }

        public void ExecuteSqlCommand(string p)
        {
            this.Database.ExecuteSqlCommand(p);
        }

        bool ContextI.AutoDetectChangedEnabled
        {
            get
            {
                return this.Configuration.AutoDetectChangesEnabled;
            }
            set
            {
                this.Configuration.AutoDetectChangesEnabled = value;
            }
        }
      
    }
}
于 2013-11-26T21:49:51.093 に答える
0

私もそれについて考えていました、私はあなたがそれを嘲笑 DbContextするために使うつもりだと思います. DbSetモック化されたクラスのためにとにかく独自の手動で実装する必要があることを除いて、その理由はわかりません(とにかく独自のインターフェースを書き直す必要があります)。

于 2017-11-22T01:52:07.567 に答える
-13

役に立たないため、IDbContext はありません。唯一の実装は DbContext です。

この設計会議のメモを見ると、EF チームも IDbSet でこのように進んでいます。

私にとって、単体テストに関する EF の本当の問題は、DbContext の DbConnection です。幸いなことに、これを埋め始めるコードプレックスに関する素晴らしいプロジェクトの努力があります。

Effort は、Entity Framework ベースのアプリケーションの自動テストを簡単に作成できる強力なツールです。これは基本的に、従来の外部データベースではなく、軽量のインプロセス メイン メモリ データベースですべてのデータ操作を実行する ADO.NET プロバイダーです。このプロバイダーを既存の ObjectContext または DbContext クラスで非常に簡単に使用できるようにするいくつかの直感的なヘルパー メソッドも提供します。既存のコードに簡単に追加するだけで、外部データベースがなくても実行できるデータ ドリブン テストを作成できます。

これにより、DbContext と DbSet をそのままにして、単体テストを簡単に実行できます。これに関する唯一の欠点は、Linq プロバイダー間の違いであり、一部の単体テストは実際のバックエンドでは成功せずに成功する可能性があります。

EF7で更新

IDbContext は役に立たず、問題は DbConnection にあると私はまだ主張しています。

EF7 には IDbContext もありません。単体テストを行うために、現在はインメモリ プロバイダーを提供しています。

Rowan Miller がデモを行っているのは、こちら: Modern Data Applications with Entity Framework 7です。

于 2013-09-11T22:39:39.053 に答える