之前的小项目做完了，到了总结经验和更新学习笔记的时间了。开始正题之前先啰嗦一下，对之前的学习目标进行一个调整：“根据代码生成表”与“生成数据库脚本和变更脚本”合并为“Code First模式日常使用篇”，增加现在这篇“错误汇总”，增加“Code First模式与其他模式混合使用与Fluent API篇”，“生成视图”因为这次在项目中没有使用，最后研究后再写出来。
通过项目实战，觉得EF并不像之前想象中的这么容易上手。问题不是EF设计的不好，EF使用起来其实相当便捷，多数数据库操作一两行代码就能搞定，基本不需要自己写SQL。问题主要有两点：EF的学习资源基本局限在官方网站，因为EF更新相对比较快，各种书籍资料更不上很正常；再就是EF初学者很容易遇到问题，各种问题……这篇文章的主要目的就是跟大家分享项目的整个过程中遇到的问题。
这次项目中遇到的问题主要可以分为以下几类：
1. 配置文件问题
2. Visual Studio编译和程序集问题
3. 数据库问题
4. 代码问题（导航属性外键关联，linq中的Convert）
其中第4点，代码问题可能的情况非常多，只说一下我遇到的一两个问题。
1. 配置文件问题
配置文件的问题在第二篇学习笔记中提到了，这里只做简单的总结。
配置文件涉及的问题可能有如下一些情况：
1. 数据库连接字符串配错了，常见的有数据库服务器名称、数据库名拼写错误。
2. 数据库连接字符串里的用户名密码没有登录权限或者密码过期了了。
3. 数据库连接字符串配置项的name值与Context的名称不一致找不到。
4. EF会使用VS中设置的启动项目的配置文件（Web.config或App.config）工作，而启动项目中刚好没有正确配置EF
2. Visual Studio编译和程序集问题
在项目开发过程中有一次用svn客户端的清理功能把所有忽略的文件清理掉了，包括编译生成的obj和Bin文件夹。再次编译时发现WCF端方法报错：
无法为具有固定名称“System.Data.SqlClient”的 ADO.NET 提供程序加载在应用程序配置文件中注册的实体框架提供程序类型“System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer”。请确保使用限定程序集的名称且该程序集对运行的应用程序可用。有关详细信息，请参阅 http://go.microsoft.com/fwlink/?LinkId=260882。
经过查找，发现是WCF项目的Bin文件夹下缺少EntityFramework.SqlServer.dll这个程序集导致的。可能是自己EF使用有问题，也可能是EF的一个bug。我在Db层引用了这个程序集，然后在WCF项目中引用了Db项目，最后Db引用的程序集却没有拷贝到WCF中。
3. 数据库问题
数据库可能出的问题也挺多，如果项目的数据库不是项目独占，而是共用的，有些表可能是共享的。比如这次做的这个项目，因为是一个工具性质的项目，依赖另一个正在开发的系统的几张表。其实这种用法就会有很多问题，首先这是一种后面要介绍到的Code First和Database First两种模式的混合模式。其次两个系统之间的耦合度十分高，对方系统表如果有一定的变更就会影响到系统，当时为了节省接口开发的工作量就直接采用数据库访问了。
说了这么多，第一个可能遇到的问题就是数据库结构发生了变化，跟代码里的实体不一致了，比如表名或字段名发生了变化。
另一个问题是数据库的账号权限有问题，开发的时候很多人可能会使用sa账号登录数据库，开发的时候一点问题也没有，可是到部署的时候，就可能出现这样那样的问题。昨天客户在部署系统，告诉我部署出问题部署不了，远程看了下，发现了两个问题，其中一个问题就是数据库账号权限的问题。客户建的账号里只有一个public权限，没有DataReader和DataWriter，这肯定是不行的。因为客户坚持另一个系统也用的这个账号，能正常访问。我将信将疑亲自试了一把，没有DataReader和DataWriter的情况下，账号连到SSMS里一张表也看不见，查询直接报错，找不到对象，加上DataReader就立马能查询了，可是插入、更新和删除都不行，加上DataWriter后正常。
开发过程中还遇到过另一个系统的负责人将Code First迁移用到的__MigrationHistory表删掉了，导致无法新增迁移的情况。这个表删掉了，系统还是能正常工作的，只是更新数据库和新增迁移时会很麻烦，我是将我自己的表全删掉，重新更新数据库，然后才能新增迁移的。这样测试数据就全丢失了，好在不重要。后来经过查询资料，得知EF6开始，可以自定义__MigrationHistory的名称了，有兴趣可以看msdn上的这篇文章。
另外还听说数据库版本是2000使用EF会有问题，也有说2005也可能有问题的，这次没有验证过，因为开发时候用的是SQL Server 2008r2。
4. 代码问题
刚使用EF的时候对导航属性并没有太多概念，在导航属性上没有加virtual关键字，在使用过程中发现导航属性都没有加载出来。原来不加virtual关键字就不会启用延迟加载特性，不过可以手动使用积极加载（Eagerly Loading）的方式让EF加载导航属性，而且是非延迟的。只需要使用DbQuery<TResult>的Include方法即可。这一点有时可能需要用到。有兴趣可以参考msdn上的这篇文章。
另一个问题则是在使用EF时，以为EF可以像以前使用的linq表达式一样随意写，在有些条件判断的地方用到了System.Convert下的函数，结果在运行时就报错了。因为EF是要把linq表达式转换为sql语句的，而System.Convert和其他一些函数是不支持转换为sql语句的，因此在使用ef的时候需要注意，如果有需要，可以事先转换好。
暂时记下的问题就是这些，以后发现新的问题再补充。
通过项目实战，觉得EF并不像之前想象中的这么容易上手。问题不是EF设计的不好，EF使用起来其实相当便捷，多数数据库操作一两行代码就能搞定，基本不需要自己写SQL。问题主要有两点：EF的学习资源基本局限在官方网站，因为EF更新相对比较快，各种书籍资料更不上很正常；再就是EF初学者很容易遇到问题，各种问题……这篇文章的主要目的就是跟大家分享项目的整个过程中遇到的问题。
这次项目中遇到的问题主要可以分为以下几类：
1. 配置文件问题
2. Visual Studio编译和程序集问题
3. 数据库问题
4. 代码问题（导航属性外键关联，linq中的Convert）
其中第4点，代码问题可能的情况非常多，只说一下我遇到的一两个问题。
1. 配置文件问题
配置文件的问题在第二篇学习笔记中提到了，这里只做简单的总结。
配置文件涉及的问题可能有如下一些情况：
1. 数据库连接字符串配错了，常见的有数据库服务器名称、数据库名拼写错误。
2. 数据库连接字符串里的用户名密码没有登录权限或者密码过期了了。
3. 数据库连接字符串配置项的name值与Context的名称不一致找不到。
4. EF会使用VS中设置的启动项目的配置文件（Web.config或App.config）工作，而启动项目中刚好没有正确配置EF
2. Visual Studio编译和程序集问题
在项目开发过程中有一次用svn客户端的清理功能把所有忽略的文件清理掉了，包括编译生成的obj和Bin文件夹。再次编译时发现WCF端方法报错：
无法为具有固定名称“System.Data.SqlClient”的 ADO.NET 提供程序加载在应用程序配置文件中注册的实体框架提供程序类型“System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer”。请确保使用限定程序集的名称且该程序集对运行的应用程序可用。有关详细信息，请参阅 http://go.microsoft.com/fwlink/?LinkId=260882。
经过查找，发现是WCF项目的Bin文件夹下缺少EntityFramework.SqlServer.dll这个程序集导致的。可能是自己EF使用有问题，也可能是EF的一个bug。我在Db层引用了这个程序集，然后在WCF项目中引用了Db项目，最后Db引用的程序集却没有拷贝到WCF中。
3. 数据库问题
数据库可能出的问题也挺多，如果项目的数据库不是项目独占，而是共用的，有些表可能是共享的。比如这次做的这个项目，因为是一个工具性质的项目，依赖另一个正在开发的系统的几张表。其实这种用法就会有很多问题，首先这是一种后面要介绍到的Code First和Database First两种模式的混合模式。其次两个系统之间的耦合度十分高，对方系统表如果有一定的变更就会影响到系统，当时为了节省接口开发的工作量就直接采用数据库访问了。
说了这么多，第一个可能遇到的问题就是数据库结构发生了变化，跟代码里的实体不一致了，比如表名或字段名发生了变化。
另一个问题是数据库的账号权限有问题，开发的时候很多人可能会使用sa账号登录数据库，开发的时候一点问题也没有，可是到部署的时候，就可能出现这样那样的问题。昨天客户在部署系统，告诉我部署出问题部署不了，远程看了下，发现了两个问题，其中一个问题就是数据库账号权限的问题。客户建的账号里只有一个public权限，没有DataReader和DataWriter，这肯定是不行的。因为客户坚持另一个系统也用的这个账号，能正常访问。我将信将疑亲自试了一把，没有DataReader和DataWriter的情况下，账号连到SSMS里一张表也看不见，查询直接报错，找不到对象，加上DataReader就立马能查询了，可是插入、更新和删除都不行，加上DataWriter后正常。
开发过程中还遇到过另一个系统的负责人将Code First迁移用到的__MigrationHistory表删掉了，导致无法新增迁移的情况。这个表删掉了，系统还是能正常工作的，只是更新数据库和新增迁移时会很麻烦，我是将我自己的表全删掉，重新更新数据库，然后才能新增迁移的。这样测试数据就全丢失了，好在不重要。后来经过查询资料，得知EF6开始，可以自定义__MigrationHistory的名称了，有兴趣可以看msdn上的这篇文章。
另外还听说数据库版本是2000使用EF会有问题，也有说2005也可能有问题的，这次没有验证过，因为开发时候用的是SQL Server 2008r2。
4. 代码问题
刚使用EF的时候对导航属性并没有太多概念，在导航属性上没有加virtual关键字，在使用过程中发现导航属性都没有加载出来。原来不加virtual关键字就不会启用延迟加载特性，不过可以手动使用积极加载（Eagerly Loading）的方式让EF加载导航属性，而且是非延迟的。只需要使用DbQuery<TResult>的Include方法即可。这一点有时可能需要用到。有兴趣可以参考msdn上的这篇文章。
另一个问题则是在使用EF时，以为EF可以像以前使用的linq表达式一样随意写，在有些条件判断的地方用到了System.Convert下的函数，结果在运行时就报错了。因为EF是要把linq表达式转换为sql语句的，而System.Convert和其他一些函数是不支持转换为sql语句的，因此在使用ef的时候需要注意，如果有需要，可以事先转换好。
暂时记下的问题就是这些，以后发现新的问题再补充。
