EF和Dapper之争的关键

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

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

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

 

我看了文章,也看了评论(但没看完)。老实讲,我觉得

 

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

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

面向对象的拥趸们,就推出了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的呀!

 

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

咳咳,这腔调越来越像老师了。是的, 

18
0
 
 
 
 
唉 道理一堆 关键是思维变不过来啊
  
 
拜见飞哥大佬,打卡碎觉。。
EF和Dapper都用过,感觉都很好用的,Dapper可以使用匿名对象作为sql的参数也是很爽的啊,哈哈哈~~~~
  
 
支持大佬
关键字:
50000+
5万行代码练就真实本领
17年
创办于2008年老牌培训机构
1000+
合作企业
98%
就业率

联系我们

电话咨询

0532-85025005

扫码添加微信