A背景

The ADO.NET Framework 支持两种数据访问体系结构模型:

1. 面向连接
2. 断开的

面向连接的数据访问体系结构 应用程序与数据源建立连接,然后通过SQL请求与数据源交互 使用相同的连接 (例如,即使应用程序不使用任何数据库操作,也必须在应用程序和数据源之间保持开放连接)。

连接的体系结构是指您不断地访问数据库以执行您希望执行的任何CRUD(创建、读取、更新和删除)操作。这会增加数据库的流量,但通常速度要快得多,因为您应该处理较小的事务。

它建立在类的基础上 Connection , Command , DataReader 和 Transaction .

在断开连接的数据访问体系结构中 ADO。net使用内存中的数据存储,可以同时保存多个表(它们是以前提取的)。

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

它基于类 联系 , DataAdapter , CommandBuilder , DataSet 和 DataView .

连接和断开体系结构的一些关键类

• 数据读取器 是 连接的体系结构 因为它保留了 连接打开,直到所有行都被逐个取出。
• 数据集 是 断开连接的体系结构 因为所有的记录都是 立即带来,无需保持连接。
• 数据适配器 作为连接和 断开连接的对象。它管理数据源和 Dataset 通过将数据源中的数据填充到 数据集 .

在期望的情况下,哪一个更好?

已连接模式

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

断开连接模式

• 它是面向断开连接的。
• 我们使用 数据集 对象
• 它的速度和性能都很低。
• 它可以保存多个数据表。
• 我们可以执行更新、插入、删除等所有选项。

回答您的问题

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

Web应用可以被连接或断开, 事实上ASP。NET应用程序已断开连接 ,由于ADO。NET断开连接的模型。由于简单的实现和更容易的故障排除,断开连接的模型越来越流行。用ASP。NET应用程序将在数据操作完成后立即关闭所有数据库连接,无论是每月15次还是每秒15次。

有人能用一个真实生活的类比来简单地解释吗 这两种模式有什么区别?

是的,假设你有一些重要的提示要告诉朋友。 断开的 意思是你期待见到他的方式,或者你正在花时间获取更多的提示。 有联系的 当你和他住在一起或与他进行在线/实时交流时,他会告诉你每一次你想要的提示。

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

EF使用 断开的 模型因为您处理数据并进行所需的更改,然后执行 SaveChanges :)

应用程序的类型(web表单、MVC、WPF、, WCF)和EF中使用的专用模型?

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

何时使用连接的模型,何时使用断开连接的模型(使用 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

ADO.Net

ADO中的“Connected”和“disconnected”。净额为 关于数据库连接 A. DataReader 总是具有打开的连接, DataSet / DataAdapter 必要时连接到数据库。

在ADO。净术语,实体框架始终以断开模式运行。 EF的每个数据库操作都会打开和关闭数据库连接(除非您显式重写此行为)。这是这里唯一重要的事情。无需详述(dis)连接的ADO.Net的详细信息。可以说,一般来说,不建议长时间保持数据库连接打开。

软件体系结构

在软件架构中,“已连接”和“已断开”通常指 1层与N层 在1层应用(例如WPF应用)中,用户界面和数据访问层(DAL)在相同的应用过程中运行。UI“连接”到DAL。并不是说它将始终与数据库保持开放连接,而是数据库始终可用。DAL从数据存储中提取的对象可以在UI和 相同的对象 可以返回到DAL并保存到数据存储(为此使用新的数据库连接)。

在N层应用程序中,UI通过网络连接与数据访问层“断开连接”。假设DAL是web服务的一部分。web服务通常是无状态的:它生成响应并忘记它们。此外,对象将在连接的两端进行序列化和反序列化。当响应进入导线时,对象就消失了。

实体框架

正如您现在所怀疑的,在EF世界中,“disconnected”指的是后者的含义,即N层应用程序。

在一层应用程序中,您可以选择具有一个上下文( DbContext )在UI中进行任何修改时,生成实体并保存相同的实体。无需将它们重新附加到新上下文。(让一个上下文保持这么长时间是否明智是另一个问题)。

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

为什么要将实体显式地附加到断开连接的模型中的上下文

如果你读到建筑内涵中的“断开连接”,这一切都是有意义的。在实体框架文档中,有一个 entire chapter on this topic .

因此,您的问题

何时使用连接模型,何时使用断开模型(使用EF)

可以回答如下:

• 从ADO。从网络的角度来看,别无选择(除了一些特殊情况),EF是断开连接的(如:不保持连接打开)。
• 从体系结构的角度来看,当应用程序是N层时,别无选择:它总是断开连接(如:分离和重新连接,实体不会被创建 和 通过相同上下文保存)。
  只有在1层应用程序中,才可以选择连接场景。在这种情况下,应谨慎管理上下文生命周期。当上下文包含“多”个对象时,它会变得缓慢且占用内存。当上下文的寿命很长时,很难让任何应用程序保持快速。在我看来,即使在一层应用程序中,断开连接的场景也应该受到青睐。