实体框架：为什么DbContext是具体的类而不是抽象类？

Question

我想知道为什么DbContext类，它是使用实体框架时的核心类是一个具体的类。

事实上，我们从不直接使用这个类，只能继承它。

将它宣布为抽象是不是更清洁？它成为具体课程的原因是什么？

Answer 1

  

......我们从不直接使用这个类...

虽然主要通过 从中导出类型并向其添加基于DbSet的其他属性，但可以在其中使用<＆em> ＃39;自己的权利：

using System;
using System.Data.Entity;
using System.Data.Entity.Infrastructure;

namespace PlayAreaCSCon
{
    class Program
    {
        static void Main(string[] args)
        {
            var mb = new DbModelBuilder();
            mb.RegisterEntityType(typeof(Foo));
            var pinfo = new DbProviderInfo("System.Data.SqlClient", "2008");
            var ctx = new DbContext("Server=.;Database=Flange;Integrated Security=SSPI;",
                     mb.Build(pinfo).Compile());
            ctx.Set<Foo>().Add(new Foo { ID = 1 });
            ctx.SaveChanges();
            Console.ReadKey();
        }
    }

    public class Foo
    {
        public int ID { get; set; }
    }
}

刚刚在我的Foos数据库中创建了一个Flange表并插入了一行。由于它本身就完全正常运作，如果他们选择这样做，就不会有原因阻止人们像这样使用它。

Answer 2

只有做出此决定的人才能确定。但请注意，DbContext中没有必须由子类提供的行为，因此如果您将其设为抽象 - 那只是因为您想要阻止直接使用它。但可以直接使用：

using (var ctx = new DbContext("EntityConnectionString")) {
    var errors  = ctx.Set<Error>().ToArray();
    Console.WriteLine(errors.Length);
}

如果您传递实体连接字符串（或app.config中的名称） - 它可以从您的emdx模型构建模型（并且它也可以直接在其他场景中使用）。有了它，您可以像往常一样进行查询，保存更改等，而不是使用DbSet方法声明Set<T>属性。

由于单独使用时没有破坏 - 我认为没有太多理由通过抽象来阻止它。