实体框架的优化应该考虑的角度--决定技术选型

&引言

之前一直带的项目--廊坊一中考评系统在做1.0的时候，怎么都没有上线，这是我们的第一个版本，使用的框架可以说是很新的框架：

实体层：entity Framework

远程数据访问：WCF

前台：MVC

1.0之所以没有上线的原因其实很简单，前台页面相应太慢，后来，我们综合了很多方面，意识到了问题：数据访问层太慢。

&EntityFramework框架的优势体现在：

1、本身给我们编写好了映射代码，不需要我们去维护，每次数据库进行变更的时候，我们只需要更新或者添加表就可以了。

2、它不需要你创造大的数据访问层，D的代码都已经给我们生成好了。

3、它提供了LINQ查询数据库，这样我们不需要写SQL语句了。

&但是同样的它自身存在缺陷：

1、不支持大数据Bulk插入

2、不支持频繁的更新操作

3、同时，当我们的表不是严格按照凡是进行设计的时候，它就不能很好的支持映射了，这个时候我们只能自己手动维护。

4、EF的Context上下文不是线程安全的。

当考评系统开始的时候，大概每个老师大概要给300多个老师进行评分，这样我们一个老师就会有300条信息插入，一中300名教师，这样就是大概有上万条的数据进行插入。频繁的继续打开Context上下文获取一个单表，并关闭它，经过一段时间，就出现了内存泄露的情况。

&&如何避免EF不支持大数据Bulk插入？

内存泄露其实就是该内存空间使用完毕之后未回收，而为了避免这样情况我们要是保持Context一直打开的情况，其实这并不是最重要的，不要为wcf每一个请求创建一个Context对象，当数据量达到一个数量级的时候，我们才对数据进行提交就行了。

&&如何避免EF不支持频繁的更新操作？

这个是目前EF都没有办法避免的问题，这个时候，我们只能使用使用SQl语句进行扬长避短了。

&&数据库表的设计会不会影响我们的查询的速度？

我想说，并不影响，先前我认为，我们可以用字段表将多张表合并，后来，我发现，这样做并没有多大的意义，因为你的第一：基本的数据映射都已经为我们写好了，一张表和多张表并不需要我们手动维护；第二：多张表好维护，因为在交接的时候，我直接可以从表的名称上面判断出来这张表中存在哪些数据，如果我们用字段表就不好看出来了。

另外：我先前认为数据库表设计应该尽可能的严格按照第三范式来设计，这样，我们就更好进行维护。1.0版本就是按照这样的设计思路进行设计的，这样其实是很好的，但是2.0的时候，我尝试了打破第三范式的约束继续数据库表的设计，将本该作为数据的外键的属性字段，作为了表中的普通属性字段，这样业务逻辑就会简单很多，但是不利于扩展。

&结束语：

我们在数据库设计的时候，一定要考虑到那些功能是需要大数据访问的，我们在这些地方一定要考虑到逻辑的复杂性，以及数据库访问量的问题。如果逻辑太过复杂的时候，我们就需要考虑到重新设计数据库，如果这个数据库访问量大的话，我们就需要用SQl语句，并且，我们要考虑到数据量特别大的时候，需要用到线程和分布式等等。