对Entity Framework的疑问——你们一般实例化几个Entity Container
最近在用Entity Framework开发项目一直有一个这样的疑问
就是对一个项目而言到底应该实例化几个Entity Container
例如 Entity Framework生成的 Entity Container 为 TestEntity
其包含了 User
我们如果要访问User
就应该
TestEntity _db=new TestEntity();
var users=(from u in _db.User
select u).ToList();
就ORM而言 整个项目的数据应该保持统一
那么 就应该只实例化 一个TestEntity 所有的数据操作都在这个对象下进行
我目前使用的是Singleton模式
但是这样做不知道会不会造成数据库连接无法及时释放、大数据量（经常单表数据在100W以上）时服务器性能下降甚至崩溃的问题
如果实例化多个TestEntity的对象 又会造成不同对象中的数据不一致的问题
不知道大家是否有相同的疑问
你们在实际应用中都是怎么处理的
讨论一下 回复给分 --------------------编程问答-------------------- --------------------编程问答-------------------- 没试过，一般大一点的项目都不使用这样的东西，不可控的东西太多了。 --------------------编程问答-------------------- 没用过，帮忙顶
--------------------编程问答-------------------- 未遇到过。ding --------------------编程问答--------------------
但是微软Entity Framework的目标应该是企业级开发吧 --------------------编程问答-------------------- 我觉得这个按照部署来定，如果是B/S、单机版、window服务，那么只要一个就可以了，如果是C/S，要两个就行了，我的观点，不一定正确，微软的Entity Framework我也没有正式的用过。 --------------------编程问答-------------------- 有没有用Entity Framework做过企业级项目开发的朋友
帮忙解释一下 --------------------编程问答-------------------- 如果有连接必要，那就用新建一个（最好用using语句），千万不要用SingleTon（这个模式不能乱用。。。），
否则，在并发情况下，什么莫名奇妙的问题都会出来
（当然，如果lz很牛B，搞定了并发问题，用SingleTon也未尝不可） --------------------编程问答-------------------- 实体（Entities）存在于实体集(Entity Set)中。而实体集又定义在实体容器（Entity Container）中。
同一个实体窗口中，可能存在多个由相同实体类构成的不同实体集
参考 --------------------编程问答-------------------- 还没用过呢，怎么用的呀，请楼下的高人帮助下 --------------------编程问答-------------------- --------------------编程问答--------------------
如果在每次需要访问数据库的时候都去新建
这样的访问效率应该会大大降低
特别是Entity Framework既然作为一个ORM的框架推出
如果每次都新建的话 必然失去了其作为数据持久层的意义
至于并发情况 我查到的资料是 Entity Framework 对并发只有两种处理模式
一个是忽略并发 也就是以最后的提交为准 第二个就是乐观并发 也就是抛出一个异常让用户选择放弃还是继续提交
目前好像不支持悲观并发，如果要做估计得用存储过程加锁来实现
如果在项目中 很少出现不同用户操作同一数据的情况 我觉得其提供的两种方式已可以处理大多数问题
--------------------编程问答--------------------
你提供的参考我已看
其中只是一个简单的事例
我现在需要知道的是
多用户环境、大数据量的系统中
Entity Framework的具体应用情况 --------------------编程问答-------------------- 先提一个问题，
如果用SingleTon，那么只有一个Context，那么只有一个DbConnection
那么在并发的时候，因为只有一个实例，所以，所有的请求都将有这一个Context去完成
如果一个线程正在用这个DbConnection读取数据，而另一个线程已经完成操作，要求关闭这个DbConnection
那么会发生什么？
不客气地说，lz的这个想法纯粹是滥用/错用SingleTon模式 --------------------编程问答--------------------
不能使用单例，这是很典型的古老的客户端软件时代的 DAO 开发思维——很多以前习惯了 Delphi/VB 的朋友沿袭下来的固有思维。
原因很简单：DAO 年代的开发，并不是针对网络，而是单机版。到后来为顺应互联网应用的潮流，DAO 演进到了 ADO，以至于后来的 ADO.NET，并不是简单的技术上的升级换代，而是开发模式的调整——其关键在于单机版变为网络环境变化带来的“并发”问题。
至于“每次访问数据库时，都需要打开数据库带来的性能问题”——已经由其他方式来解决了，不必过虑：ADO和ADO.NET等数据库访问接口层面（数据访问Provider）、数据库（无论是SqlServer还是Oracle），都提供了连接池类似的性能优化技术——在不同层次尽最大限度优化对数据库连接的使用。
因此，从DAO年代写程序时，打开一个数据库连接并尽可能共用这一个数据库连接，到ADO年代“使用时打开数据库连接，用完立即关闭”（使用时申请，用完立即释放），原因就在于访问模型的变化（主要是并发）了。
呵呵，很多年来的确有很多书籍、错误的例子——他们往往缘于一些比较有经验的老程序员，因此虽然已经越来越少，但仍然能时不时在一些地方见到。让我们一起来努力，彻底改变类似的状态吧。 --------------------编程问答-------------------- 我们的做法是：一个页面只有一个数据库连接（dataContext），在这个页面上的所有操作共享一个数据库连接 --------------------编程问答-------------------- 如果你多个页面都采用一个数据库连接，在处理事务时如果提交失败，将导致全部回滚！，一个页面一个DataContext相对比较灵活！ --------------------编程问答-------------------- Entity本身不保证所有操作都是线程安全的，所以只用一个在并发情况下可能会产生错误。所以每次使用创建一个新的entity，用完立即刷新，即可以提高并发度又不会产生错误。
--------------------编程问答-------------------- EF 4的效率比传统的ado。net 要好很多 特别是在数据量大的时候，至于创建几个模型，哪就看实际需要了，你也可以根据功能创建几个模型，这样的话开发的时候思路还清晰，如果是小的项目，一个模型就够用了，至于数据库连接什么时候释放，我推荐还是手动释放，特别是在数据量大的时候。 --------------------编程问答-------------------- 我试过了
绝对不要单例 entity framework
在多线程并发的时候
该单例绝对会发生 已多次映射内部字段 的错误 （本人测试了无数次了）
实际测试中发现只有 new entity framework 才可以保证并发的时候不会报错
--------------------编程问答-------------------- 我是把 new抽出来 放在另外个类里面
补充：.NET技术 , C#
