EF

Question

我对连接模型感到困惑，并且在实体框架中断开连接。

我使用传统的ADO.net（DataReader用于连接模型，DataAdapter用于断开连接的模型） 当我需要将数据发送到其他进程时，我有很多用户需要更新或插入以及在一些情况下断开模型时，我知道我使用连接模型对内存中的数据进行一些操作并将其发回到db。

现在我在EF阅读了一些关于连接模型和断开连接模型的文章，我很困惑为什么要将实体明确地附加到断开连接模型中的上下文？ 我还读到了web中的默认行为是断开连接的模型，而WPF中的默认行为是连接模型！

• 有人可以用简单的方式解释现实生活中的类比 这两个模型有什么区别？
• 我们如何用简单的例子处理EF中的两个模型？
• 应用类型（网络表单）之间是否存在关联 ，MVC，WPF，WCF）和EF中使用的专用模型？
• 何时使用连接型号以及何时使用断开型号（使用EF）？

Answer 1

背景

The ADO.NET Framework支持两种数据访问架构模型：

1. 面向连接
2. 断开

在面向连接的数据访问体系结构中，应用程序建立与数据源的连接，然后使用相同的连接通过SQL请求与之交互（例如，必须打开连接）在应用程序和数据源之间进行维护，即使它没有使用任何数据库操作。）

连接架构是指您经常前往数据库进行任何您希望执行的CRUD（创建，读取，更新和删除）操作。这会为数据库创建更多流量，但通常会更快，因为您应该进行较小的事务。

它建立在课程Connection，Command，DataReader和Transaction上。



在断开连接的数据访问体系结构中，ADO.net使用可以同时容纳多个表的内存数据存储（它们之前被提取）。

断开连接的体系结构是一种从数据库中检索记录集并存储它的方法，使您能够对内存中的数据执行许多CRUD（创建，读取，更新和删除）操作，然后可以重新同步重新连接时使用数据库。

它建立在课程Connection，DataAdapter，CommandBuilder，DataSet和DataView上。



连接和断开连接架构的一些关键类

• DataReader是 Connected Architecture ，因为它保留了 连接打开，直到逐个获取所有行。
• DataSet是断开连接的架构，因为所有记录都是 立即带来，没有必要保持连接活着。
• DataAdapter充当Connected与之间的桥梁 断开的对象。它管理数据源和数据源之间的连接 Dataset将数据源中的数据填充到Dataset。

哪一个在所需的情况下更好？

连接模式

• 面向连接
• 我们使用DataReader对象
从数据库中读取数据
• 其方法提供更快的性能
• 它可以保存单个表的数据
• 它是只读的，我们无法更新数据

断开连接模式

• 它已断开连接导向。
• 我们使用DataSet对象从数据库中读取数据。
• 速度和性能都很低。
• 它可以容纳多个数据表。
• 我们可以执行所有选项，如更新，插入，删除等。

回答你的问题

  

现在我读了一些关于连接模型和断开模型的文章   在EF和我迷惑为什么我应该明确地附加实体   断开模型中的上下文？我也读过默认版   Web中的行为是断开连接的模型，并且在WPF中是连接模型！

由于ADO.NET断开连接模型，Web应用程序可能已连接或断开连接，实际上ASP.NET应用程序已断开连接。由于简单的实施和更容易的故障排除，断开连接的模型越来越受欢迎。无论是每月15次点击还是每秒15次点击，ASP.NET应用程序的良好设计都会在数据操作完成后立即关闭所有数据库连接。

  

有人可以用简单的方式解释现实生活中的类比   两个模型之间有什么区别？

是的，假设您有一些重要提示告诉/了解朋友。 已断开连接表示您等待他或您花时间获取更多提示的方式。 已连接是您与他住在一起或与他进行在线/实时通信的方式，以便每次都能告诉每个小费。

  

我们如何用简单的例子处理EF中的两个模型？

EF使用已断开连接模型。因为您处理数据并进行所需的更改，然后执行SaveChanges：）

  

应用类型（网络表单，MVC，WPF，是否存在关系）   WCF）和EF中使用的专用模型？

它基于应用程序逻辑。实时应用程序需要连接，因为它们需要按时传播和更新，而不是其他应用程序类型。

  

何时使用连接模型以及何时使用断开连接的模型（使用   EF）？

我已经回答了这个问题。我想说的是，通过仅在最短的时间内保持连接打开，ADO.NET可以节省系统资源并为数据库提供最大的安全性，同时对系统性能的影响也较小。根据您的应用策略/类型，您可以自己做出正确的决定。

<强>更新：

  

但是如果我处于断开连接的模型中，你能告诉我EF的情况吗？   处理来自许多用户的多个操作（INSERT，UPDATE，DELETE）   在同一时间？

查看ObjectStateManager，它负责与上下文中的对象跟踪相关的所有内容。 如果某些用户对同一条目执行并发更新，则默认情况下，实体框架实现乐观并发模型。这意味着在查询数据和更新数据之间，数据源中的数据不会保留锁定。 实体框架将对象更改保存到数据库而不检查并发性。对于可能经历高度并发性的实体（如银行系统），我们建议实体在概念层中定义属性属性ConcurrencyMode="fixed"，如以下示例所示：

<Property Name="Status" Type="Byte" Nullable="false" ConcurrencyMode="Fixed" />

使用此属性时，实体框架会在保存对数据库的更改之前检查数据库中的更改。任何冲突的更改都会导致OptimisticConcurrencyException，当您定义使用存储过程对数据源进行更新的实体数据模型时也会发生这种情况。在这种情况下，当用于执行更新的存储过程报告更新了零行时，会引发异常。有关更多信息，请访问Saving Changes and Managing Concurrency

Answer 2

ADO.Net

ADO.Net中的“已连接”和“已断开连接”有关数据库连接。 DataReader始终具有开放连接，DataSet / DataAdapter二人组在必要时连接到数据库。

我认为一个常见的现实生活类比就是拨打电话。如果你想让一个朋友在你开车的路上和你说话，你会更喜欢'连接模式'：在电话通话期间，你会来回谈话直到你在那里。为每条指令开始新的电话是非常耗时的 但是，如果你问你住在两个街区外的母亲，检查你是否关闭了厨房的窗户，你会打电话给她，她会去检查并给你回电话：'断开连接'。与此同时，你将继续做你正在做的事情。

从这个意义上讲，Entity Framework始终以断开连接模式运行。 EF的每个数据库操作都会打开并关闭数据库连接（除非您明确覆盖此行为）。

软件架构

但在软件架构中，“连接”和“断开连接”通常指的是 1层与N层。在1层应用程序中，例如WPF应用程序，用户界面和数据访问层（DAL）在同一应用程序进程中运行。 UI与DAL“连接”。并不总是与数据库建立开放连接，但数据库始终可用。可以在UI中处理DAL从数据存储中提取的对象，并且可以将相同的对象返回到DAL并保存到数据存储中。

在N层应用程序中，UI通过网络连接与数据访问层分离，“断开连接”。假设DAL是Web服务的一部分。 Web服务通常是无状态的：它会产生响应并忘记它们。此外，对象将在连接的两侧进行序列化和反序列化。当响应进入电线时，物体就会消失。

实体框架

正如您现在所怀疑的那样，在EF世界中，“断开连接”指的是后一种含义，即N层应用。

在1层应用程序中，您可以选择生成实体的上下文（DbContext），并在UI中进行任何修改时保存相同的实体。无需将它们重新附加到新的上下文中。 （长时间保持上下文是否合理是一个不同的问题）。

在N层应用程序中，上下文生成实体或保存实体，而不是两者。它生成了序列化的实体并且处理了上下文。从客户端应用程序返回的实体被反序列化并重新附加到保存其更改的新上下文实例。这是你困惑的根源......

  

为什么我应该将实体明确地附加到断开连接模型中的上下文

如果你在建筑内涵中读到“断开连接”，这一切都是有意义的。 Lerman和Miller在他们的书中描述了整个过程 Programming Entity Framework：DbContext 第4章：使用包含N层应用程序的断开连接的实体。

现在你的问题

  

何时使用连接型号以及何时使用断开型号（使用EF）

可以这样回答：

• 从ADO.Net的角度来看，没有选择（保存一些特殊情况），EF工作断开连接（如：不会打开连接）。
• 从架构的角度来看，当应用程序是N层时别无选择：它总是断开连接（如：分离和重新连接，实体不是通过相同的方式保存和上下文）。
  只有在单层应用程序中才有选择。这种选择将我们带到了上下文生命周期管理领域。关于这一点已经说了很多。一个不可否认的事实是，当它包含“许多”对象时，上下文变得缓慢且占用内存。当上下文有很长的生命周期时，很难让任何应用程序保持活跃，所以即使在数据量很大的1层应用程序中，也应该认真考虑断开连接（分离）的场景。