你必须知道的EF知识和经验

工欲善其事，必先利其器。

我们使用EF和在很大程度提高了开发速度，不过随之带来的是很多性能低下的写法和生成不太高效的sql。

虽然我们可以使用SQL Server Profiler来监控执行的sql，不过个人觉得实属麻烦，每次需要打开、过滤、清除、关闭。

在这里强烈推荐一个插件MiniProfiler。实时监控页面请求对应执行的sql语句、执行时间。简单、方便、针对性强。

如图：(具体使用和介绍请移步)

数据准备

新建实体：Score（成绩分数表）、Student（学生表）、Teacher（老师表）

后面会给出demo代码下载链接

foreach循环的陷进

1.关于延迟加载

请看上图红框。为什么StudentId有值，而Studet为null？因为使用code first，需要设置导航属性为virtual，才会加载延迟加载数据。

2.关于在循环中访问导航属性的异常处理（接着上面,加上virtual后会报以下异常）

"已有打开的与此 Command 相关联的 DataReader，必须首先将它关闭。"

解决方案：

• 方案1、设定ConnectionString加上MultipleActiveResultSets=true,但只适用于SQL 2005以后的版本
• 方案2、或者先读出放置在List中

3.以上两点仅为热身，我们说的陷阱才刚刚开始！

然后我们点击打开MiniProfiler工具（不要被吓到）

解决方案：使用Include显示连接查询（注意:需要手动导入using System.Data.Entity 不然Include只能传表名字符串）。

再看MiniProfiler的监控（瞬间101条sql变成了1条，这其中的性能可想而知。）

AutoMapper工具

上面我们通过Include显示的执行表的连接查询显然是不错的，但还不够。如果我们只需要查询数据的某些字段呢，上面查询所有字段岂不是很浪费内存存储空间和应用程序与数据库数据传输带宽。

我们可以：

对应监控到的sql：

我们看到生成的sql，查询的字段少了很多。只有我们显示列出来字段的和一个StudentId，StudentId用来连接查询条件的。

是的，这样的方式很不错。可是有没有什么更好的方案或方式呢？答案是肯定的。（不然，也不会在这里屁话了。）如果表字段非常多，我们需要使用的字段也非常多，导航属性也非常多的时候，这样的手动映射就显得不那么好看了。那么接下来我们开始介绍使用AutoMapper来完成映射：