EF中的连通模型和断开模型

Question

我对连接模型和实体框架中的断开连接很困惑.

我使用的是传统的ADO.net(DataReader用于连接模型和DataAdapter断开连接的模型),当我需要发送更多用户需要更新或插入以及在几种情况下断开模型时,我知道我使用连接模型数据到其他进程对内存中的数据进行一些操作并将它们发送回数据库.

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

---

• 有人能用简单的方式解释现实生活中的两个模型之间的区别吗？
• 我们如何用简单的例子来处理EF中的两个模型？
• 应用程序的类型(Web表单,MVC,WPF,WCF)与EF中使用的专用模型之间是否存在关系？
• 何时使用连接模型以及何时使用断开模型(使用EF)？

Answer 1

背景

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

1. 面向连接
2. 断开的

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

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

它是建立在类Connection,Command,DataReader和Transaction.

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

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

它建立在类Connection,DataAdapter和CommandBuilder,DataSet和DataView.

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

• DataReader是连接体系结构,因为它保持连接打开,直到逐个获取所有行.
• DataSet是断开连接的体系结构,因为所有记录都是立即生成的,并且不需要保持连接存活.
• DataAdapter充当连接和断开对象之间的桥梁.它管理数据源之间的连接,并 Dataset通过将数据源中的数据填充到Dataset.

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

连接模式

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

断开模式

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

回答你的问题

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

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

有人能用简单的方式解释现实生活中的两个模型之间的区别吗？

是的,假设你有一些重要的提示告诉/了解朋友.断开连接意味着你等待看到他的方式,或者你花时间获得更多的提示.连接是你与他住在一起的方式,或者在他每次需要时告诉每个提示进行在线/实时通信.

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

EF使用Disconnected模型.因为您使用数据并进行所需的更改然后执行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

Answer 2

ADO.Net

ADO.Net中的"已连接"和"已断开连接"是关于数据库连接的.A DataReader始终具有开放连接,DataSet/ DataAdapterduo在必要时连接到数据库.

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

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

软件架构

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

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

实体框架

正如您现在所怀疑的那样,在EF世界中,"断开连接"指的是后一种含义,即N层应用程序.

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

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

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

如果你在建筑内涵中读到"断开连接",这一切都是有意义的.Lerman和Miller在其编程实体框架:DbContext第4章:使用包括N层应用程序的断开实体的书中描述了整个过程.

现在你的问题

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

可以这样回答:

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