EF 中的连接模型和断开连接模型
connected model and disconnected model in EF
我对连接模型很困惑，在 entity framework 中断开连接。
我使用的是传统的 ADO.net（DataReader 用于连接模型，DataAdapter 用于断开连接模型）
我所知道的是，当我有很多用户需要更新或插入在一起时，我使用连接模型，而在某些情况下，当我需要将数据发送到其他进程时，我使用断开连接的模型对内存中的数据进行一些操作并将它们发回到数据库 .
现在我阅读了一些有关 EF 中的连接模型和断开连接模型的文章，我很困惑为什么我应该将实体显式附加到断开连接模型中的上下文？
我还读过 web 中的默认行为是断开连接的模型，而 WPF 中的默认行为是连接模型！
- 谁能用现实生活中的类比来简单解释一下
两种型号有什么区别？
- 我们如何通过简单的示例在 EF 中处理这两个模型？
- 应用程序类型（网络表单）之间是否存在关系
, MVC, WPF, WCF) 和 EF 中使用的专用模型?
- 何时使用连接模型以及何时使用断开模型（使用 EF）？
一个背景
The ADO.NET Framework 支持两种数据访问架构模型：
- 面向连接
- 断开连接
在面向连接的数据访问架构中，应用程序建立到数据源的连接，然后通过 SQL 请求与它交互 连接（例如，必须在您的应用程序和数据源之间保持打开的连接，即使它没有使用任何数据库操作）。
连接架构是指您不断访问数据库以执行您希望执行的任何 CRUD（创建、读取、更新和删除）操作。这会产生更多的数据库流量，但通常速度要快得多，因为您应该处理较小的事务。
它建立在 类 Connection、Command、DataReader 和 Transaction 的基础上。
在断开连接的数据访问架构中，ADO.net 使用内存中的数据存储，可以同时保存多个 table（它们是以前取过）。
断开连接的架构是一种从数据库中检索记录集并存储它的方法，使您能够对内存中的数据执行许多 CRUD（创建、读取、更新和删除）操作，然后可以重新-重新连接时与数据库同步。
它基于 类 Connection、DataAdapter、CommandBuilder、DataSet 和 DataView.
Connected 和 Disconnected 架构的一些关键类
DataReader 是 Connected Architecture 因为它保留了
连接打开，直到所有行都被一一提取。DataSet 是 Disconnected Architecture 因为所有记录都是
立即带来，无需保持连接。DataAdapter 充当 Connected 和
断开连接的对象。它管理数据源和
Dataset 通过将数据源中的数据填充到 Dataset。
在理想情况下哪个更好？
连接模式
- 面向连接
- 我们使用
DataReader 对象从数据库中读取数据
- 其方法提供更快的性能
- 可以容纳单个table
的数据
- 它是只读的，我们不能更新数据
断开连接模式
- 面向断开连接
- 我们使用
DataSet 对象从数据库中读取数据。
- 它的速度和性能都很低。
- 它可以容纳多个 table 数据。
- 我们可以执行所有选项，如更新、插入、删除等
您的问题的答案
Now I read some articles about connected model and disconnected model
in EF and I'm confused why should I attach explicitly the entities to
the context in disconnected model? I had read also that the default
behavior in web is disconnected model and in WPF is connected model !
Web 应用程序可以连接或断开连接，并且，事实上 ASP.NET 应用程序已断开连接，由于 ADO.NET 断开连接的模型。由于简单的实施和更容易的故障排除，断开连接的模型越来越受欢迎。 ASP.NET 应用程序的良好设计会在数据操作完成后立即关闭所有数据库连接，无论是每月 15 次点击还是每秒 15 次点击。
Could someone explain in easy manner with an an analogy of real life
what's the difference between the two models?
是的，假设您有一些重要提示要 tell/aware 给朋友。 断开连接 表示您等待见到他的方式，或者您正在花时间获得更多要说的提示。 联系 是您与他同住或与他online/RealTime 沟通的方式，每次您需要时都会告诉他每条提示。
How we could handle both models in EF with simple example?
EF 使用 Disconnected 模型。因为您处理数据并进行所需的更改，然后执行 SaveChanges :)
Is there a relationship between the type of app (web form , MVC, WPF,
WCF) and the dedicated model used in the EF?
它基于应用程序逻辑。实时应用程序需要连接，因为它们需要实时传播和更新，而不是其他应用程序类型。
When to use connected model and when to use disconnected model (using
EF) ?
我已经回答了这个问题。我想说的是，ADO.NET 通过保持连接打开的时间最短，可以节省系统资源并为数据库提供最大的安全性，同时对系统性能的影响也较小。这取决于你的应用strategy/type，你可以自己做出一个好的决定。
更新:
but if i was in a disconnected model, Could you tell me how the EF can
handle multiple operations (INSERTs,UPDATEs,DELETEs) from many users
at the same time?
看看 ObjectStateManager，它负责上下文中与对象跟踪相关的所有内容。 如果一些用户对同一个条目执行并发更新，默认情况下，Entity Framework实施乐观并发模型。这意味着在查询数据和更新数据之间不会对数据源中的数据持有锁。 Entity Framework将对象更改保存到数据库而不检查并发性。对于可能遇到高并发性的实体（如银行系统），我们建议实体定义一个属性在属性为ConcurrencyMode="fixed"的概念层中，如下例所示：
<Property Name="Status" Type="Byte" Nullable="false" ConcurrencyMode="Fixed" />
使用此属性时，Entity Framework 在将更改保存到数据库之前检查数据库中的更改。任何有冲突的更改都会导致 OptimisticConcurrencyException which can also occur when you define an Entity Data Model that uses stored procedures to make updates to the data source. In this case, the exception is raised when the stored procedure that is used to perform updates reports that zero rows were updated. For more information visit Saving Changes and Managing Concurrency
ADO.Net
'Connected'和ADO.Net中的'disconnected'是关于数据库连接。 DataReader 总是有一个打开的连接，DataSet/DataAdapter 二人组在必要时连接到数据库。
我认为现实生活中一个常见的类比是拨打 phone 电话。如果你想让一个朋友在你开车的时候带你去他家，你会更喜欢 'connected mode'：在 phone 通话期间你来回交谈直到你到达那里。为每条指令启动一个新的 phone 调用太耗时了。
但是，如果您让住在两个街区外的母亲检查您是否关闭了厨房 window，您会打电话给她，她会去检查并给您回电：“断开连接”。与此同时，您将继续做您正在做的事情。
从这个意义上说，Entity Framework 始终在断开连接模式下运行。 EF 的每个数据库操作都会打开和关闭数据库连接（除非您明确覆盖此行为）。
软件架构
但是在软件架构中，'connected'和'disconnected'通常指的是1-tier vs. N-tier。在 1 层应用程序中，例如 WPF 应用程序，用户界面和数据访问层 (DAL) 运行 在同一个应用程序进程中。 UI 对 DAL 来说是 'connected'。并不是说它总是与数据库有一个开放的连接，而是数据库总是可用的。 DAL 从数据存储中获取的对象可以在 UI 中处理，相同的对象可以 return 编辑到 DAL 并保存到数据存储中。
在 N 层应用程序中，UI 通过网络连接与数据访问层分开，'disconnected'。假设 DAL 是 Web 服务的一部分。 Web 服务通常是无状态的：它产生响应并忘记它们。此外，对象将在连接的两端进行序列化和反序列化。当响应进入线路时，对象就消失了。
Entity Framework
正如您现在所怀疑的那样，在 EF 世界中 'disconnected' 指的是后一种含义，即 N 层应用程序。
在 1 层应用程序中，您可以选择拥有一个上下文 (DbContext)，它可以在 UI 中进行任何修改时生成实体并保存相同的实体。无需将它们重新附加到新的上下文中。 （保持上下文存活那么久是否明智是另一个问题）。
在 N 层应用程序中，上下文要么生成实体 ，要么 保存实体，而不是两者。它生成序列化的实体并处理上下文。 return 来自客户端应用程序的实体被反序列化并重新附加到保存其更改的新上下文实例。这就是你困惑的根源...
why should I attach explicitly the entities to the context in disconnected model
看建筑内涵'disconnected'就明白了。 Lerman 和 Miller 在他们的书 Programming Entity Framework: DbContext 第 4 章：Working with Disconnected Entities Including N-Tier Applications 中描述了整个过程.
现在你的问题
When to use connected model and when to use disconnected model (using EF)
可以这样回答：
- 从 ADO.Net 的角度来看，别无选择（除了一些特殊情况），EF 在断开连接的情况下工作（如：不保持连接打开）。
- 从体系结构的角度来看，当应用程序是 N 层时别无选择：它始终断开连接（如：分离和重新附加，不创建实体和 通过相同的上下文保存）。
只有在 1 层应用程序中才有选择。这个选择将我们带到上下文生命周期管理领域。关于这一点已经说了很多。一个不可否认的事实是，当上下文包含 'many' 个对象时，它会变慢并消耗内存。当上下文的生命周期很长时，很难保持任何应用程序的快速运行，因此即使在数据密集型 1 层应用程序中，也应认真考虑断开连接（分离）的情况。
我对连接模型很困惑，在 entity framework 中断开连接。
我使用的是传统的 ADO.net（DataReader 用于连接模型，DataAdapter 用于断开连接模型）
我所知道的是，当我有很多用户需要更新或插入在一起时，我使用连接模型，而在某些情况下，当我需要将数据发送到其他进程时，我使用断开连接的模型对内存中的数据进行一些操作并将它们发回到数据库 .
现在我阅读了一些有关 EF 中的连接模型和断开连接模型的文章，我很困惑为什么我应该将实体显式附加到断开连接模型中的上下文？ 我还读过 web 中的默认行为是断开连接的模型，而 WPF 中的默认行为是连接模型！
- 谁能用现实生活中的类比来简单解释一下 两种型号有什么区别？
- 我们如何通过简单的示例在 EF 中处理这两个模型？
- 应用程序类型（网络表单）之间是否存在关系 , MVC, WPF, WCF) 和 EF 中使用的专用模型?
- 何时使用连接模型以及何时使用断开模型（使用 EF）？
一个背景
The ADO.NET Framework 支持两种数据访问架构模型：
- 面向连接
- 断开连接
在面向连接的数据访问架构中，应用程序建立到数据源的连接，然后通过 SQL 请求与它交互 连接（例如，必须在您的应用程序和数据源之间保持打开的连接，即使它没有使用任何数据库操作）。
连接架构是指您不断访问数据库以执行您希望执行的任何 CRUD（创建、读取、更新和删除）操作。这会产生更多的数据库流量，但通常速度要快得多，因为您应该处理较小的事务。
它建立在 类 Connection、Command、DataReader 和 Transaction 的基础上。
在断开连接的数据访问架构中，ADO.net 使用内存中的数据存储，可以同时保存多个 table（它们是以前取过）。
断开连接的架构是一种从数据库中检索记录集并存储它的方法，使您能够对内存中的数据执行许多 CRUD（创建、读取、更新和删除）操作，然后可以重新-重新连接时与数据库同步。
它基于 类 Connection、DataAdapter、CommandBuilder、DataSet 和 DataView.
Connected 和 Disconnected 架构的一些关键类
DataReader是 Connected Architecture 因为它保留了 连接打开，直到所有行都被一一提取。DataSet是 Disconnected Architecture 因为所有记录都是 立即带来，无需保持连接。DataAdapter充当 Connected 和 断开连接的对象。它管理数据源和Dataset通过将数据源中的数据填充到Dataset。
在理想情况下哪个更好？
连接模式
- 面向连接
- 我们使用
DataReader对象从数据库中读取数据 - 其方法提供更快的性能
- 可以容纳单个table 的数据
- 它是只读的，我们不能更新数据
断开连接模式
- 面向断开连接
- 我们使用
DataSet对象从数据库中读取数据。 - 它的速度和性能都很低。
- 它可以容纳多个 table 数据。
- 我们可以执行所有选项，如更新、插入、删除等
您的问题的答案
Now I read some articles about connected model and disconnected model in EF and I'm confused why should I attach explicitly the entities to the context in disconnected model? I had read also that the default behavior in web is disconnected model and in WPF is connected model !
Web 应用程序可以连接或断开连接，并且，事实上 ASP.NET 应用程序已断开连接，由于 ADO.NET 断开连接的模型。由于简单的实施和更容易的故障排除，断开连接的模型越来越受欢迎。 ASP.NET 应用程序的良好设计会在数据操作完成后立即关闭所有数据库连接，无论是每月 15 次点击还是每秒 15 次点击。
Could someone explain in easy manner with an an analogy of real life what's the difference between the two models?
是的，假设您有一些重要提示要 tell/aware 给朋友。 断开连接 表示您等待见到他的方式，或者您正在花时间获得更多要说的提示。 联系 是您与他同住或与他online/RealTime 沟通的方式，每次您需要时都会告诉他每条提示。
How we could handle both models in EF with simple example?
EF 使用 Disconnected 模型。因为您处理数据并进行所需的更改，然后执行 SaveChanges :)
Is there a relationship between the type of app (web form , MVC, WPF, WCF) and the dedicated model used in the EF?
它基于应用程序逻辑。实时应用程序需要连接，因为它们需要实时传播和更新，而不是其他应用程序类型。
When to use connected model and when to use disconnected model (using EF) ?
我已经回答了这个问题。我想说的是，ADO.NET 通过保持连接打开的时间最短，可以节省系统资源并为数据库提供最大的安全性，同时对系统性能的影响也较小。这取决于你的应用strategy/type，你可以自己做出一个好的决定。
更新:
but if i was in a disconnected model, Could you tell me how the EF can handle multiple operations (INSERTs,UPDATEs,DELETEs) from many users at the same time?
看看 ObjectStateManager，它负责上下文中与对象跟踪相关的所有内容。 如果一些用户对同一个条目执行并发更新，默认情况下，Entity Framework实施乐观并发模型。这意味着在查询数据和更新数据之间不会对数据源中的数据持有锁。 Entity Framework将对象更改保存到数据库而不检查并发性。对于可能遇到高并发性的实体（如银行系统），我们建议实体定义一个属性在属性为ConcurrencyMode="fixed"的概念层中，如下例所示：
<Property Name="Status" Type="Byte" Nullable="false" ConcurrencyMode="Fixed" />
使用此属性时，Entity Framework 在将更改保存到数据库之前检查数据库中的更改。任何有冲突的更改都会导致 OptimisticConcurrencyException which can also occur when you define an Entity Data Model that uses stored procedures to make updates to the data source. In this case, the exception is raised when the stored procedure that is used to perform updates reports that zero rows were updated. For more information visit Saving Changes and Managing Concurrency
ADO.Net
'Connected'和ADO.Net中的'disconnected'是关于数据库连接。 DataReader 总是有一个打开的连接，DataSet/DataAdapter 二人组在必要时连接到数据库。
我认为现实生活中一个常见的类比是拨打 phone 电话。如果你想让一个朋友在你开车的时候带你去他家，你会更喜欢 'connected mode'：在 phone 通话期间你来回交谈直到你到达那里。为每条指令启动一个新的 phone 调用太耗时了。
但是，如果您让住在两个街区外的母亲检查您是否关闭了厨房 window，您会打电话给她，她会去检查并给您回电：“断开连接”。与此同时，您将继续做您正在做的事情。
从这个意义上说，Entity Framework 始终在断开连接模式下运行。 EF 的每个数据库操作都会打开和关闭数据库连接（除非您明确覆盖此行为）。
软件架构
但是在软件架构中，'connected'和'disconnected'通常指的是1-tier vs. N-tier。在 1 层应用程序中，例如 WPF 应用程序，用户界面和数据访问层 (DAL) 运行 在同一个应用程序进程中。 UI 对 DAL 来说是 'connected'。并不是说它总是与数据库有一个开放的连接，而是数据库总是可用的。 DAL 从数据存储中获取的对象可以在 UI 中处理，相同的对象可以 return 编辑到 DAL 并保存到数据存储中。
在 N 层应用程序中，UI 通过网络连接与数据访问层分开，'disconnected'。假设 DAL 是 Web 服务的一部分。 Web 服务通常是无状态的：它产生响应并忘记它们。此外，对象将在连接的两端进行序列化和反序列化。当响应进入线路时，对象就消失了。
Entity Framework
正如您现在所怀疑的那样，在 EF 世界中 'disconnected' 指的是后一种含义，即 N 层应用程序。
在 1 层应用程序中，您可以选择拥有一个上下文 (DbContext)，它可以在 UI 中进行任何修改时生成实体并保存相同的实体。无需将它们重新附加到新的上下文中。 （保持上下文存活那么久是否明智是另一个问题）。
在 N 层应用程序中，上下文要么生成实体 ，要么 保存实体，而不是两者。它生成序列化的实体并处理上下文。 return 来自客户端应用程序的实体被反序列化并重新附加到保存其更改的新上下文实例。这就是你困惑的根源...
why should I attach explicitly the entities to the context in disconnected model
看建筑内涵'disconnected'就明白了。 Lerman 和 Miller 在他们的书 Programming Entity Framework: DbContext 第 4 章：Working with Disconnected Entities Including N-Tier Applications 中描述了整个过程.
现在你的问题
When to use connected model and when to use disconnected model (using EF)
可以这样回答：
- 从 ADO.Net 的角度来看，别无选择（除了一些特殊情况），EF 在断开连接的情况下工作（如：不保持连接打开）。
- 从体系结构的角度来看，当应用程序是 N 层时别无选择：它始终断开连接（如：分离和重新附加，不创建实体和 通过相同的上下文保存）。
只有在 1 层应用程序中才有选择。这个选择将我们带到上下文生命周期管理领域。关于这一点已经说了很多。一个不可否认的事实是，当上下文包含 'many' 个对象时，它会变慢并消耗内存。当上下文的生命周期很长时，很难保持任何应用程序的快速运行，因此即使在数据密集型 1 层应用程序中，也应认真考虑断开连接（分离）的情况。