以前我做大项目中,我就提到要用entity framework 来做大项目的框架.可惜当时被否决了,由于当时自己对entity framework 也了解的并不是很深,所以当时也没有力争. 今年回到公司后,做了一个公司的小项目,就用的是entity framework. 因此也有时间好好研究该项目了.同时也做了大量的压力测试,觉的大项目还是能用 entity framework的.
首先我们先说一个项目的框架,要考虑哪些因素.
1,易用性.这点很重要,作为一个框架,要能够快速的写出业务代码出来,这样才能帮助项目节省成本.
2.可扩展性和可维护性. 一个框架的改变虽然不多,但改变有时总是不可避免的.因为随着需求的变化,用户的访问量增大.你会发现当初的框架会越来越不适合项目了.当达到一定程度的时候,就必须要下决心去优化架构了.
3.高性能. 一个好的框架,必须要能经得起性能的考验.一个性能低下的框架,肯定会让用户无法接受的.当然,高性能和易用性可能存在一定的矛盾.关键是能找到平衡点.而且高性能也可以通过硬件的投入来解决.(后面章节,会介绍负载均衡的部署)
4.容易学习. 作为一个框架,一定要能让项目成员快速学习.不要让一个成员要一两个星期,还只是勉强适应.这就是框架的失败地方了.
5.迅速定位. 开发人员在开发中难免会犯一些这样或那样的错误.所以我们在开发底层框架中,要能做相应的检查,并能做出有意义的错误提示,使得开发人员能快速定到问题所在.
因此这段时间,我也在好好研究相关的架构.首先找的是orm框架.因为根据我过去的各种项目经验,觉的一个合适的orm框架,对于快速开发是一个多么重要的.如果没有orm框架,我们就要花很多时间去写相关的数据查询工作.
目前Orm框架,.net普遍采用的有2种.一种是微软的entity framework. 一种是由java那里引过来的nhibernate.我一开始,也对这2框架作了一下研究对比.虽然他们之间各有长处.但我觉的用 entity framework 应该更适合我们项目的开发.主要原因如下:
- Entity framework 用的是linq 查询语言.这个相信很多.net 开发的人员都会.而nhibernate 用的是它自己的Hibernate Query Language (HQL).这个熟悉的人会比较少,虽然这些都可以快速学习.但是如果要精通,还是要时间的.
- entity framework 是微软主推的.目前它的更新进度非常快.而且它也不断推出新功能出来. 如entity framework 5 已对性能有了极大的提高. 具体可查看博客http://www.infoq.com/news/2012/02/EF-5. 而即将推出的entity framework 6.会实现异步查询功能.
- Nhibernate 的使用比entity framew 复杂的多.当然,它 的复杂性,也有一定好处,带来了更多的可扩展性. 但我我觉的这种东西是对于我们大部分项目来说,是缺点大于优点的.
有关entity framework 和 nhibernate 的区别可参看如下文章http://weblogs.asp.net/ricardoperes/archive/2012/06/07/differences-between-nhibernate-and-entity-framework.aspx
当然用entity framework 作为底层框架.它也存在一些问题.但随着自己的研究,我也逐渐解决了这些问题.
- 是表太多,比如1,2百张表.这在大项目中相当普遍的.
对于这种现象,我们可以通过视图的方式,把这些表发布在不同视图.这样就可以使我们的实体设计器,变的比较好看和容易维护.
2.是夸库中,如何实现连接查询.
对于一些大型项目,往往会分几个业务库.但这些业务库往往会跟一个主库有关联关系.比如用户表,部门表等人员基本信息.对于这种情况,我想的是把基本库的一些主要信息缓存起来,然后用缓存的信息去跟业务库进行关联查询.如要根据业务库userId去主库查人名.这个我们完全可以把业务库数据查出来,然后再用userid去查缓存获取人名.
3.是批量修改和删除
目前Entity framework 没有批量删除和修改的方法,如果我们采用先批量查询出来实体,然后再一个一个去做删除或修改,这样务必会造成生成一大堆的语句.肯定会严重影响效率的. 虽然我们可以通过直接组装sql语句,或通过存储过程来操作.但这毕竟是下策.其实我们可以扩展entity framework 来实现linq方式进行批量删除和修改.(相关的方法,我将会在后续的章节介绍)
4.使用过程中发现很多地方性能不好.
其实这往往是由于开发人员不了解entity framework属性造成的.写的语句有问题.就好像一个不熟悉sql语句的人,写出来的语句,性能会有很大的差别.就拿我优化过的一个业务方法,当时我同事写的方法,一开始用压力测试10个,都老报死锁问题,而且平均时间要50多秒.后来我优化了.压力测20个也是3,4秒钟.(我们这个业务方法是比较复杂,有大量的数据插入和更改,我们是按实际环境中的用户数来压的).而且也很少报错.
因此我觉的我们要解决这方面的问题,在进行entity framework 开发时,必须要进行一些培训,由一些有经验的同事进行讲解,并形成文档,以供大家参考.同时在开发中也要进行code review .随时发现开发中的一些问题.这样就可以确保我们项目的质量.(有关如何提高entity framework的性能的文章,我也会在以后发布)
这是我关于entity framework 的一些研究,当然毕竟我还没有把entity framwwork用于大项目,这其中或许有其他问题. 但我相信车到山前必有路.只要大的方向没错,其他都好解决. 而且我始终相信,不管是ado.net, enterprise database, 还是entity framework 都是把生成的语句送到数据库去查询获取数据. 只不过entity framework 多了一个把lingq 语句转成sql ,需要一定的时间消耗,随着微软的推动,这方面的消耗已经越越少了.再说,解决这些性能问题,我们还可以增加硬件的投入来获取,不一定要用花大量人员开发来获取.毕竟人的成本比机器的会高很多.
接下来的章节,我会像大家介绍我做的对 entity framework 和ado.net的性能对比.到时我们会发现在一些情况下, entity framework 比ado.net的性能更好.