有人说EF 很慢， 比较重
在没有接触EF之前， 确实有这种想法， 真的，因为不了解。一直用惯了Dapper后， 就不想用别的【主要是我需要哪些数据，就写Sql查询哪些数据， 绝不会多查一个字段】
刚到新公司之后， 他们用的就是EF, 我当时有点诧异， 心想EF这么慢的东西都敢用， 现在想想，自己有所傻x,就应为不知道就干乱下结论。
其实真正用的过程中， 发现EF也有很多优点， 少些sql语句， 导航属性查询等， 确实方便多了。 但是在用的过程中， 难免会用到不当的地方。 下面就是我在优化的过程中做点吐槽。
1、分页问题（真假分页问题）
项目中很多代码用到分页，前期开发的时候， 数据量少， 即使用到了假分页也很难感觉出来【如： 构建一个list，里面插入20条数据， 通过Take来获取，感觉还行， 那么如果该List中有2w 条数据， 你会有这样的想法吗 】
假分页：query.ToList().Skip((PageIndex - 1) * PageSize).Take(PageSize);
解释：查询全部数据，获取分页数
真分页：query.Skip((PageIndex - 1) * PageSize).Take(PageSize).ToList();
解释：查询分页需要数据
2、导航属性问题（其实这个名词是老员工说的，我就沿用）
什么是导航属性？
（本人没有细作研究，就大概说一下自己的感觉：表实体于表实体之间的关系）
我是做电商的， 会员，地址， 购物车， 订单， 订单商品数据等都会和会员关联起来。没啥问题， 我们会员通过导航属就可以获取其他数据， 方便的很。下图就是
但是，但是 如果只需要地址， 没必要把真个Customer 传入过来啊， 其他数据没必要知道， 但是项目中把这些数据都放在一起， 喜欢传入大的实体， 让我感觉很难过，我是中途加入，但是项目已经很乱了， 无法区分表示体，业务实体 model等。
所以：建议更具业务需求， 适当加导航属性， 没必要见一个加一个。
还有：表实体， 业务逻辑实体， 页面的Model，做一下区分。
有使用EF的同学， 推荐看看
http://blog.csdn.net/column/details/entityframework.html