优化一

有人说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