Question

我刚刚开始学习实体框架（从5.0开始）并遇到一些问题。在Pluralsight上观看了几个视频之后，我决定发挥创意并创建一个继承自DbContext的抽象基类，并公开了一个属于泛型类型的DbSet的“DataContext”属性。像这样：

public abstract class BaseDataContext<E> : DbContext
     where E : CustomEntity
{
      public DbSet<E> DataContext {get;set;}

      public BaseDataContext()
      {
           Database.SetInitializer<BaseDataContext<E>>(null);
      }
 }

在我开始处理彼此有关系的实体（父母/孩子）之前，这似乎很有效。发生的事情是当我试图通过继承BaseDataContext的数据类向数据库添加一个新的子实体而不是仅仅附加引用（意思是，带着孩子说“你的父键是123”），它创造了另一个记录父项的新键和所有其他字段重复，并使此新记录成为子项的父项。我尝试设置我的孩子的key属性（使用数据公开的属性为空），但这并没有改变任何东西。我在SO（here）上发现了一个线程，它表示像我试图做的那样做多个数据上下文并不是一个好主意，似乎可以解释到底发生了什么。

我的问题是，随着人气的普及，惠普似乎正在为所有人增加，这是常见的做法吗？要创建一个单独的数据上下文，然后在各处传递构造函数？还是有一种更常见的简单方法？如果事情进入后台线程，这将特别适用，因为传递上下文可能会变得困难。

提前致谢！

Answer 1

当您按预期使用时，您可以充分利用EF作为任何工具。所以你问的很好。实体框架，特别是代码优先，完全是关于持久性无知（解释here for example）。我不知道您的评论“就像您在EF / L2S之前所做的那样”，但听起来像active record。这不是可行的方法。

上下文负责实现商店中的实体，跟踪更改并保存对数据库的更改。更详细：上下文管理工作单元（跟踪更改），并且DbSet成员充当基本存储库（实现和保存）。实体类本身对此一无所知。（作为旁注：在他们所使用的ObjectContext API中，但是它们可以被编码为持久性无知的。）

现在关于“多重背景”。您提到的问题是关于相同上下文类型的多个上下文实例。您的问题是关于多个上下文类型（并且必然是多个实例）。让我们解决这个问题：

上下文类型的数量：通常情况下，上下文类型的数量非常有限，通常只有一种。为什么？因为覆盖数据库的大部分的上下文能够检索并持久化许多不同的对象图。因此它服务于大量用例，现在和将来，稳定和变化，但它本身是稳定的。它仅在数据库更改时更改，而不是在应用程序更改时更改。（我应该说，虽然每个用例都有一个上下文类型的拥护者，但我发现它们不可避免地存在大量共同的类，非常混乱）。
上下文实例的数量：这个问题不能用几句话完全涵盖，但应该记住上下文（1）缓存数据和（2）跟踪和存储更改。因此，长期存在的上下文很快就会包含过时的数据，并且随着变化的发生，它们的大小也会增加共识是保持背景“短暂”，但什么是短暂的？它可以是每个http请求一个实例，每个服务调用一个，每个（业务）事务一个，但MDI接口中每个表单一个，每个线程一个......请参阅有关Linq-to-Sql上下文的有用讨论{{ 3}}，EF上下文（或NHibernate会话）也是如此。有一件事是清楚的：不要使用一个静态上下文，因为有些人很想做。

尽可能保持创造力，尽可能多地进行实验。按照预期使用EF并享受很多乐趣！

实体框架5.0约定

1 个答案: