原文地址:http://www.cnblogs.com/frankofgdc/p/3600090.html
Entity Framework学习笔记——错误汇总
通过项目实战,觉得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的时候需要注意,如果有需要,可以事先转换好。
暂时记下的问题就是这些,以后发现新的问题再补充。