EF和Dapper之争的关键

突然发现园子里为EF和Dapper的事闹翻了天。(学Java的同学大概就是Hibernate和MyBatis之争了)

讲到EF对Mysql的支持,我在一边偷着乐:还好我用的是NHibernate,对Mysql的支持可好啦,哈哈……

咳咳,这样做当然是不对的,应该批评。我检讨三秒钟,先。

 

我看了文章,也看了评论(但没看完)。老实讲,我觉得三生石上只有一句话是站得住脚的:

真正出现问题的不是 Entity Framework,而是我们,好吧,就明说了吧:我们太想念 SQL 语句了!

其他的,嗯,已经有很多人说了很多了,我就不凑热闹了。

 

不知道大家还记不记得我以前说过:

虽然我们有C#这种面向对象的语言,但实际上我们很多开发人员仍然是“面向数据库”编程。

为了避免引发更大的争论,我必须首先声明:

面向对象和面向数据库并无优劣高下之分

面向对象和面向数据库并无优劣高下之分

面向对象和面向数据库并无优劣高下之分

重要的事说三遍。

 

选择Dapper,甚至ADO.NET拼SQL,本质上就是“面向数据库”编程。什么意思呢?所有的开发过程是以数据库为基础的,整个系统的架构是以数据库的库表结构为依托的。当遇到一个业务逻辑的时候,首先想到的是这数据放在哪几张表里的,用什么SQL语句把它们给取出来,然后才想着怎么把这些数据封装成类……这就是我所谓的“面向数据库”编程。

那么与之相对的,什么是“面向对象编程”呢?

忘掉数据库,尤其是关系型数据库,我以前讲过,你可以想象成这数据最终是存放在XML文件里的、存放在NoSQL里的、存放在其他什么什么磁盘里面的。当然,最理想的,是有一个“对象数据库”,所有的数据都是以对象形式存放的,数据与数据之间就是对象与对象的关系,有继承有引用,都是Load出来.出来的。总之,SQL语句完全不管用。所以,遇到一个业务逻辑的时候,首先想到的就是这些数据存放在哪些对象里面,怎么加载这些对象……

明白了吧?这才是“面向对象”的思路!

哪里有什么表,哪里有什么SQL?我们眼里只有对象!万物皆对象,阿弥陀佛……

 

但是,世上的事情啊,最怕就是这个但是!

没有“对象数据库”,只有“关系数据库”啊?这是一个始终无法回避的问题:几乎所有的企业级应用,都是以关系数据库为存储器的。这下就麻烦了,怎么办呢?

面向对象的拥趸们,就推出了ORM(Object Relational Map),在“对象”和关系数据库“表”之间做一个映射,希望能解决这个问题。大家一定要明白,ORM是O开头的,其核心其要义,是把object映射成Relational的表,Object是第一位的。而不是很多同学那样,把ORM当成一个SQL语句生成器或者SQL语言的封装,其作用就是“不写SQL”。不是这样的,本末倒置了呀,同学!那么,从这个意义上讲,Dapper就不算是一个ORM(不做定义上的争论,大家理解意思就行),他就是一个理想的DBHelper而已。

相应的,EF作为一个沉重的ORM工具,就被嫌弃了。这是自然而然的,我不知道我说明白了没有,当你的思维是“面向数据库”的时候,ORM确实是一种负担,不仅仅是因为它的“沉重”,更因为它遮蔽了SQL实现的细节:看不到SQL,我心里不踏实啊!还要特么的设个断点查查log看看生成的SQL啥样子的,这就憋屈了……

而且ORM在复杂对象映射、复杂查询的时候,确实会出问题,现在这工具还不能说是完美。

那咋整呢?

 

我觉得这就是一个个人(或者团队)的喜好问题了。

“面向数据库”本身其实没问题。基于数据库基于表结构,CRUD,又怎么啦?回归代码的本质,也符合KISS(Keep It Stupid Simple)原则啊!不计其数的成功项目都这样完成的,而且也一直良好运作。相反的,完全的“面向数据库”设计架构的,崩了的项目也不少吧?

但是,我个人而言,更倾向于“面向对象”的思路和方向。主要有这么几个原因:

  1. 不喜欢SQL。这恐怕是决定性的原因,尤其憎恨存储过程,尤其尤其受不了那种几百上千行的存储过程,崩溃了一样的感觉。“面向数据库”的极致就是“存储过程编程”,假如都走极端,相比较而言,“面向对象”的极致我觉得都能接受——就全部代码见不着一行SQL嘛,没啥。
  2. ORM在不断的进步。EF我不熟,NHibernate5.0的很多新特性让我真的是眼前一亮,最鼓舞人心的就是Colletion上进行Query() 可以生成SQL查询而不用把整个collection加载进来。这是我期盼了不知多久的一个特性,太爽了!以前很多为了性能而做的walkaround就不需要了,代码会非常的清晰。我相信,ORM工具以后会一直进步,直到无限接近于完美,或者诞生“对象数据库”。“面向数据库”就根本不需要BLL层。把数据从数据库取出来,封装成类,何必呢?多此一举啊,完全是。就算要封装,我觉得强类型的DataSet就完全够用了。但DateSet这些已经凉了,说白了,“面向数据库编程”已经就那个样子了,能用,但没啥发展了;但ORM,还有很多人很多公司在努力的完善,还有进步的空间。
  3. 太多太多的工具或手段是必须和“面向对象”配合的。比如说单元测试,我不知道其他人怎么玩的,反正我的单元测试是隔离了数据库的,测试用的数据,直接new就OK了,又快又轻巧。混入了SQL语句或存储过程,必须连着数据库,这单元测试咋做?我还真不知道。另外的,领域驱动,“面向数据库”也没办法玩,你和“领域专家”讲表结构和SQL,人家会崩溃的。
  4. ORM保留了你在特殊情况下使用原生SQL的权利。实在不行的时候,还是可以自己写SQL的呀!

 

差不多了,我觉得可以简单总结一下,希望同学们:

  • 能够从战略高度上理解“面向对象”和“面向数据库”的区别;
  • 明白ORM的不足,但要对ORM的发展抱有信心。

咳咳,这腔调越来越像老师了。是的,人人都是程序猿 已经开课很久了,今天是第18讲,入门型普及型课程,有兴趣的同学可以听一听,或者给周围的新人宣传宣传,先谢了!

posted @ 2018-09-10 23:59  自由飞  阅读(16503)  评论(59编辑  收藏  举报