实体框架：数据文本的生命？ [英] Entity framework: life of datacontext?

问题描述

我正在阅读有关数据环境的推荐生活，但我仍然对最佳选项有疑问。

I am reading about which is the recommended life for the data context, but I still have some doubts about the best option.

一般来说，我的结论是看到在桌面应用中，数据环境的生命应该是生命的形式，而在WCF应用中，生活应该是会话的生命。

In general, the conclusion that I see is that in desktop applications the life of the data context should be the life of the form, and in WCF applications the life should be the life of the session.

理由，如果我明白，那就是数据环境的生命应该足够大，以便具有上下文工作单位的优势，但没有很大的损失。

The reason, if I understand, it's that the life of the data context should be enough large to have the advantages of the unit of work of the context but no very large to lost its benefits.

但是，例如，如果我从数据库读取一些数据，并且数据上下文作为桌面应用程序中表单的属性创建，如果我做了更改，我只需要更改实体中的值数据上下文并调用savechanges（）方法和EF保存数据上下文中的更改。所以我有两个与数据库的交互，一个是获取数据，另一个用于保存更改。

But, for example, if I read some data from the data base and the data context is create as property of the form in a desktop application, if I do changes, I only have to change the values in the entities of the data context and call the savechanges() method and EF save the changes in the data context. So I have two interactions with the data base, one to get the data and other to save the changes.

但是，这样，数据上下文可以变得非常大并且还有更多的可能性发生并发问题，我的意思是，由于我加载数据，进行更改并保存数据，其他用户有时间修改信息。

However, in this way, the data context can grow very large and also there is more probabilities that occur concurrency issues, I mean that since I load the data, make the changes and save the data, other user has time to modify the information.

如果我为每个操作使用一个数据上下文，我用一个配置的数据上下文读取数据，更改局部变量中的信息，然后在保存更改时，我必须使用其他数据上下文实体，我必须搜索实体，将信息从本地变量传递给实体，然后保存更改。

If I use a data context for each operation, I read the data with a data context that is dispose, make changes to the information in local variables and then, when I save the changes, I must use other data context, which receive again the entities, I must search for the entities for pass the information from my local variables to the entities and then save the changes.

在这种情况下，我有三个交互数据库的效率较低，数据库必须做更多的工作。一个获取结果并将信息传递给局部变量，另一个获取结果并将信息从局部变量传递到上下文，最后保存更改。此外，我必须做额外的工作来搜索第二个数据上下文中的实体，以将变化从局部变量传递给新的上下文。

In this case I have three interactions with the data base so is less efficient and the database must to do more work. One to get the results and pass the information to local variables, other to get again the results and pass the information from local variables to the context and finally the save of the changes. Also, I must do extra work to search for the entities in the second data context to pass the changes from the local variables to the new context.

然而，并发问题因为只是在第二个数据上下文中加载数据并将变化从局部变量传递到上下文之间所经过的时间。

However, concurrence issues have less probabilities to occur, because is only the time elapsed between the load of the data in the second data context and pass the changes from the local variables to the context.

所以，这是在桌面应用程序和WCF应用程序中使用数据上下文的最佳选择？也许我使用数据上下文是错误的？

So, which is the best option to work with the data context, in desktop applications and WCF applications? Perhaps I am doing a wrong using of the data context?

也许如果我使用第二种方法，我的本地变量也是实体，我可以创建第二个数据上下文，而不是从数据库加载实体，我可以直接添加本地实体，更改其状态以添加，更改或删除，然后数据上下文可以保存更改？

Perhaps if I use the second approach, and my locals variables are entities too, I can create a second data context, and instead of load entities from the database, I can add the local entities directly, changing its state to add, changed or deleted and then the data context can save the changes?

推荐答案

那么，在桌面
应用程序和WCF应用程序中，哪个是数据上下文的最佳选择？

So, which is the best option to work with the data context, in desktop applications and WCF applications?

这取决于具体情况，但在大多数情况下，这将是您需要的：

That depends on concrete situation but in most cases this will be exactly what you need:

• WinForm / WPF - 每个表单/每个演示者等。


• WCF - 每个服务调用; 从不每个会话或每个应用程序


• ASP.NET - 每个请求;每个会话或每个应用程序永不

• WinForm / WPF - per form / per presenter etc.
• WCF - per service call; never per session or per application
• ASP.NET - per request; never per session or per application

在这些情况下，每个提到的范围通常是一个工作单位。如果您在范围内有多个工作单位，您可能需要不同的上下文实例。

In these cases each mentioned scope is usually one Unit of work. If you have more than one unit of work in the scope you can need different context instancing.

最困难的情况是多线程Windows服务，您必须手动识别作品单位并使用适当的上下文生命周期。 永不在线程之间共享上下文。 避免使用用于服务多个工作单元的全局长生存环境。 这里是为什么共享上下文是一个错误的想法。 / p>

The most difficult situation is multi threaded Windows service where you must manually identify unit of works and use appropriate context lifetime. Never share context between threads. Avoid using global long living contexts used to server multiple unit of works. Here is related description why sharing the context is a wrong idea.

但是，并发问题的发生概率较少，因为
只是在第二个数据的加载之间经过的时间
数据上下文，并将更改从本地变量传递到
上下文。

However, concurrence issues have less probabilities to occur, because is only the time elapsed between the load of the data in the second data context and pass the changes from the local variables to the context.

这是对并发的误解问题。乐观并发应检查您是否覆盖了另一个线程/用户所做的更改。因此，您必须在修改前加载原始数据，因为这是您在修改之前知道的最后一个状态。如果最后一个状态与数据库中的当前状态不匹配，并发问题必须解决。必须修改您提出的解决方案以支持这一点 - 例如，当您从数据库加载数据以进行更新时，必须通过所有实体，并检查当前时间戳等于在第一次数据检索中从数据库加载的时间戳。

That is misunderstanding of concurrency problem. The optimistic concurrency should check that you are not overwriting changes made by another thread / user. So you must work with original data loaded before your modifications because that is the last state you knew before modification. If the last state doesn't match current state in the database concurrency issue must be resolved. Your proposed solution must be modified to support this - for example when you load data from the database for update you must go through all entities and check that current timestamps are equal to timestamps loaded from the database in the first data retrieval.

这篇关于实体框架：数据文本的生命？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！