艰难的抉择--请大家赐教
公司的ERP系统（实际规模比ERP大，还包括CRM,PLM),想采用ADO.NET Entity Framework来做数据访问及持久层，这段时间都在对AEF进行了解。AEF的一个好处就是对于不同数据库可以透明支持(其持久层功能对于业务系统来说没有多大的实际意义),如果仅仅是因为它的名头和不同数据库透明支持，感觉不是很好，因为对应的ObjectContext分割比较困难，不分割吧，这么大的系统（表数量至少在2000以上）也不现实，分割吧，ObjectContext之间的实体关联查询又会有问题。而且Insert,Update,Delete都没法用，只有采用框架提供的功能，遇到统计，分析等功能难道也要对着一堆实体进行？

现在感觉AEF基本就是个内存关系数据库了，我们本来就是选用的关系型数据库，为什么又要用这个呢？

AEF看起来确实简单好用，但我觉得这么大的系统能否胜任，心里没底，请问大家，有谁用这种框架做过大型系统么？

请大家说说，谢谢！

------解决方案--------------------
不太懂，帮LZ顶，学习一下
------解决方案--------------------
ADO.NET Entity Framework + LINQ应该可以做的
------解决方案--------------------
Entity Framework 没用过，不过我们是用的ORM，应该和它差不多。我们只用ORM的增删改模式，复杂的查询还是用的SQL，数据量大的时候，实体查询之间的转换确实很影响效率。
------解决方案--------------------
不太懂！学习！
------解决方案--------------------
何必呢。。何苦呢。。。。还是自己写SQL吧。。。。。
要毛个ORM。。。。这东西也是裹脚布。。。。裹得很快，解得很慢。。。。。
------解决方案--------------------
统计，分析 可以用存储过程和视图来解决。框架会自动生成
------解决方案--------------------
你愿意用就用，不愿意用就不用。对同一个项目中的别人也是如此。不要先入为主地搞什么“只许用什么什么，不许用什么什么”这种论调。有的人觉得sql好，就用sql；有的人觉得orm好，就用orm；有的人觉得linq to ef好，就用它。关键是所有代码都要经过高强度的自动化测试，有一点bug都不能带着问题继续开发。假设有些人选择了很慢的开发方法，或者不容易自我调试的开发方法，那么他的许多任务都会因为超时（比如评估为5小时的任务结果8小时还没有完成）而取消，他写的代码也就作废了，而让别人去写。这样有些人慢慢地就会向更实用的开发方法靠拢，也就不认为越是低级的东西越好了。