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讲，入门型普及型课程，有兴趣的同窗能够听一听，或者给周围的新人宣传宣传，先谢了！