Question

我必须维护一台在一台机器上运行时正常运行的应用程序。它使用的是Entity Framework 5，模型是使用数据库第一种方法创建的。

现在，应用程序已安装在第二台计算机上，并更新到由计算机A创建的数据库没有反映在第二台机器上（B）。

在应用程序的主要形式中，正在创建实体上下文：

recordEntities = new RecordEntities();

然后应用程序中的所有子表单都将传递给此原始表单 “recordEntities”

在正在读取记录的第二台机器上的表单中，代码看起来像这样

 Record = (from b in recordEntities.records
           where
           b.JobNo == JobNo &&
           b.SerialNo == SerialNo
           select b).FirstOrDefault();

通过在查询之前添加以下代码，我可以获得更新的记录。

recordEntities = new RecordEntities();
// do query

我的问题是：

有没有办法可以“刷新”'recordEntities'而无需重新创建上下文，即类似的东西：

recordEntities.Refresh();
// go on to do the query

如果我必须在查询之前每次都要继续重新创建上下文，我应该将其丢弃首先，即

recordEntities.Dispose();
recordEntities = new RecordEntities();
Record = (from b in recordEntities.records
           where
           b.JobNo == JobNo &&
           b.SerialNo == SerialNo
           select b).FirstOrDefault();

Answer 1

首先，实体框架上下文没有设计为具有长寿命。确切地说，他们缓存从数据库中获取的所有内容会导致它们立即变得臃肿。性能将受到影响，内存消耗可能变得无法忍受。

其次，无国籍是时下的常态。在Web应用程序（包括SPA）中，每个视图都是新的，预期是新的（除了跨越多个页面的特定任务，例如填写复杂的应用程序表单）。我认为这也是人们开始期待智能客户的行为。开始将智能客户端应用程序视为Web应用程序是令人耳目一新的（双关语）。

这是什么意思？

激活先前打开的表单应与新打开的表单相同。
离开表单应该以与关闭表单相同的方式处理，因此如果没有决定如何处理未保存的数据，就不可能这样做。
用户交互设计是交易性的，但跨多个表单应该作为一个连贯的来回形式表示，比如类似向导的用户体验。

这与您的问题有什么关系？这意味着上下文生命周期最多被绑定以查看生命周期（表单或向导），并且重新激活视图也可以用新数据启动新上下文。进一步说，每个数据库交互都可以有自己的上下文。

我在这里要说的是，所需的短上下文生命周期可以很好地与智能客户端应用程序中的用户交互相结合。

可能需要重新设计，例如通过分页减少一个视图中显示的数据量，而不是倾倒数千条记录，用户无论如何都无法理解这些记录。或者以不同方式管理视图状态（例如：在获取新数据时应将哪个网格记录重新选择为当前状态）。这很难（我知道，我工作的其中一个应用程序仍然远离这个阶段）但是有回报，因为它可以使更轻的客户和（可能很重要）将来转换为Web会更容易。

在实体框架5中重新创建和处理dbcontext

1 个答案: