我在阅读这对于数据上下文推荐的寿命，但我仍对最好的选择有些疑惑。
一般情况下，我看到的结论是，在桌面应用程序中的数据上下文的生活应该是这样的形式的生活，并在WCF应用程序的生命应该是会议的生活。
究其原因，如果我的理解，这是该数据上下文的生活应该是足够大，有背景的工作单位，但没有非常大的丢失它的好处的优势。
但是，举例来说，如果我从数据库中读取一些数据和数据上下文是创建作为桌面应用程序的形式的财产，如果我做的改变，我只需要改变的数据上下文的实体价值和调用调用SaveChanges（）方法和EF保存在数据上下文的变化。 所以我有一个数据库，一个两次交互来获取数据和其他保存更改。
然而，在这种方式中，数据上下文会变得非常大，也没有出现并发问题的更多可能性，我的意思是，因为我加载数据，进行更改并保存数据，其他用户有时间来修改信息。
如果我使用一个数据上下文为每个操作，我阅读是配置，使局部变量变化的信息，然后，当我保存更改，我必须用其他数据方面，它再次接收数据的上下文数据实体，我要寻找的实体从我的本地变量，实体传递的信息，然后保存更改。
在这种情况下，我有一个数据库三次互动等是效率较低，数据库必须做更多的工作。 一来得到的结果和信息传递给本地变量，其他再得到的结果和局部变量的信息传递到环境，最后保存的变化。 另外，我必须做额外的工作来搜索第二个数据对象的实体从本地变量的变化传递给新的上下文。
然而，同意问题都发生概率较小，因为只有在第二个数据上下文数据的负载之间的时间间隔，并通过从本地变量上下文的变化。
所以，这是与数据方面的工作，在桌面应用程序和WCF应用的最佳选择吗？ 也许我做的使用数据上下文的错吗？
也许，如果我使用第二种方法，我的当地人变量是实体太大，我可以创建第二个数据上下文，而不是从数据库中加载实体，我可以直接添加本地实体，其状态更改为添加，更改或删除然后将数据上下文可以保存更改？
