突然發(fā)現(xiàn)園子里為EF和Dapper的事鬧翻了天。（學(xué)Java的同學(xué)大概就是Hibernate和MyBatis之爭了）

講到EF對Mysql的支持，我在一邊偷著樂：還好我用的是NHibernate，對Mysql的支持可好啦，哈哈……

咳咳，這樣做當(dāng)然是不對的，應(yīng)該批評。我檢討三秒鐘，先。

?

我看了文章，也看了評論（但沒看完）。老實(shí)講，我覺得三生石上只有一句話是站得住腳的：

真正出現(xiàn)問題的不是 Entity Framework，而是我們，好吧，就明說了吧：我們太想念 SQL 語句了！

其他的，嗯，已經(jīng)有很多人說了很多了，我就不湊熱鬧了。

?

不知道大家還記不記得我以前說過：

雖然我們有C#這種面向?qū)ο蟮恼Z言，但實(shí)際上我們很多開發(fā)人員仍然是“面向數(shù)據(jù)庫”編程。

為了避免引發(fā)更大的爭論，我必須首先聲明：

面向?qū)ο蠛兔嫦驍?shù)據(jù)庫并無優(yōu)劣高下之分。

面向?qū)ο蠛兔嫦驍?shù)據(jù)庫并無優(yōu)劣高下之分。

面向?qū)ο蠛兔嫦驍?shù)據(jù)庫并無優(yōu)劣高下之分。

重要的事說三遍。

?

選擇Dapper，甚至ADO.NET拼SQL，本質(zhì)上就是“面向數(shù)據(jù)庫”編程。什么意思呢？所有的開發(fā)過程是以數(shù)據(jù)庫為基礎(chǔ)的，整個系統(tǒng)的架構(gòu)是以數(shù)據(jù)庫的庫表結(jié)構(gòu)為依托的。當(dāng)遇到一個業(yè)務(wù)邏輯的時候，首先想到的是這數(shù)據(jù)放在哪幾張表里的，用什么SQL語句把它們給取出來，然后才想著怎么把這些數(shù)據(jù)封裝成類……這就是我所謂的“面向數(shù)據(jù)庫”編程。

那么與之相對的，什么是“面向?qū)ο缶幊獭蹦?#xff1f;

忘掉數(shù)據(jù)庫，尤其是關(guān)系型數(shù)據(jù)庫，我以前講過，你可以想象成這數(shù)據(jù)最終是存放在XML文件里的、存放在NoSQL里的、存放在其他什么什么磁盤里面的。當(dāng)然，最理想的，是有一個“對象數(shù)據(jù)庫”，所有的數(shù)據(jù)都是以對象形式存放的，數(shù)據(jù)與數(shù)據(jù)之間就是對象與對象的關(guān)系，有繼承有引用，都是Load出來.出來的。總之，SQL語句完全不管用。所以，遇到一個業(yè)務(wù)邏輯的時候，首先想到的就是這些數(shù)據(jù)存放在哪些對象里面，怎么加載這些對象……

明白了吧？這才是“面向?qū)ο蟆钡乃悸?#xff01;

哪里有什么表，哪里有什么SQL？我們眼里只有對象！萬物皆對象，阿彌陀佛……

?

但是，世上的事情啊，最怕就是這個但是！

沒有“對象數(shù)據(jù)庫”，只有“關(guān)系數(shù)據(jù)庫”啊？這是一個始終無法回避的問題：幾乎所有的企業(yè)級應(yīng)用，都是以關(guān)系數(shù)據(jù)庫為存儲器的。這下就麻煩了，怎么辦呢？

面向?qū)ο蟮膿碥O們，就推出了ORM（Object Relational Map），在“對象”和關(guān)系數(shù)據(jù)庫“表”之間做一個映射，希望能解決這個問題。大家一定要明白，ORM是O開頭的，其核心其要義，是把object映射成Relational的表，Object是第一位的。而不是很多同學(xué)那樣，把ORM當(dāng)成一個SQL語句生成器或者SQL語言的封裝，其作用就是“不寫SQL”。不是這樣的，本末倒置了呀，同學(xué)！那么，從這個意義上講，Dapper就不算是一個ORM（不做定義上的爭論，大家理解意思就行），他就是一個理想的DBHelper而已。

相應(yīng)的，EF作為一個沉重的ORM工具，就被嫌棄了。這是自然而然的，我不知道我說明白了沒有，當(dāng)你的思維是“面向數(shù)據(jù)庫”的時候，ORM確實(shí)是一種負(fù)擔(dān)，不僅僅是因?yàn)樗摹俺林亍?#xff0c;更因?yàn)樗诒瘟薙QL實(shí)現(xiàn)的細(xì)節(jié)：看不到SQL，我心里不踏實(shí)啊！還要特么的設(shè)個斷點(diǎn)查查log看看生成的SQL啥樣子的，這就憋屈了……

而且ORM在復(fù)雜對象映射、復(fù)雜查詢的時候，確實(shí)會出問題，現(xiàn)在這工具還不能說是完美。

那咋整呢？

?

我覺得這就是一個個人（或者團(tuán)隊）的喜好問題了。

“面向數(shù)據(jù)庫”本身其實(shí)沒問題。基于數(shù)據(jù)庫基于表結(jié)構(gòu)，CRUD，又怎么啦？回歸代碼的本質(zhì)，也符合KISS（Keep It Stupid Simple）原則啊！不計其數(shù)的成功項目都這樣完成的，而且也一直良好運(yùn)作。相反的，完全的“面向數(shù)據(jù)庫”設(shè)計架構(gòu)的，崩了的項目也不少吧？

但是，我個人而言，更傾向于“面向?qū)ο蟆钡乃悸泛头较颉Ｖ饕羞@么幾個原因：

不喜歡SQL。這恐怕是決定性的原因，尤其憎恨存儲過程，尤其尤其受不了那種幾百上千行的存儲過程，崩潰了一樣的感覺。“面向數(shù)據(jù)庫”的極致就是“存儲過程編程”，假如都走極端，相比較而言，“面向?qū)ο蟆钡臉O致我覺得都能接受——就全部代碼見不著一行SQL嘛，沒啥。

ORM在不斷的進(jìn)步。EF我不熟，NHibernate5.0的很多新特性讓我真的是眼前一亮，最鼓舞人心的就是Colletion上進(jìn)行Query() 可以生成SQL查詢而不用把整個collection加載進(jìn)來。這是我期盼了不知多久的一個特性，太爽了！以前很多為了性能而做的walkaround就不需要了，代碼會非常的清晰。我相信，ORM工具以后會一直進(jìn)步，直到無限接近于完美，或者誕生“對象數(shù)據(jù)庫”。“面向數(shù)據(jù)庫”就根本不需要BLL層。把數(shù)據(jù)從數(shù)據(jù)庫取出來，封裝成類，何必呢？多此一舉啊，完全是。就算要封裝，我覺得強(qiáng)類型的DataSet就完全夠用了。但DateSet這些已經(jīng)涼了，說白了，“面向數(shù)據(jù)庫編程”已經(jīng)就那個樣子了，能用，但沒啥發(fā)展了；但ORM，還有很多人很多公司在努力的完善，還有進(jìn)步的空間。

太多太多的工具或手段是必須和“面向?qū)ο蟆迸浜系摹１热缯f單元測試，我不知道其他人怎么玩的，反正我的單元測試是隔離了數(shù)據(jù)庫的，測試用的數(shù)據(jù)，直接new就OK了，又快又輕巧。混入了SQL語句或存儲過程，必須連著數(shù)據(jù)庫，這單元測試咋做？我還真不知道。另外的，領(lǐng)域驅(qū)動，“面向數(shù)據(jù)庫”也沒辦法玩，你和“領(lǐng)域?qū)＜摇敝v表結(jié)構(gòu)和SQL，人家會崩潰的。

ORM保留了你在特殊情況下使用原生SQL的權(quán)利。實(shí)在不行的時候，還是可以自己寫SQL的呀！

?

差不多了，我覺得可以簡單總結(jié)一下，希望同學(xué)們：

• 能夠從戰(zhàn)略高度上理解“面向?qū)ο蟆焙汀懊嫦驍?shù)據(jù)庫”的區(qū)別；
• 明白ORM的不足，但要對ORM的發(fā)展抱有信心。

咳咳，這腔調(diào)越來越像老師了。是的，人人都是程序猿 已經(jīng)開課很久了，今天是第18講，入門型普及型課程，有興趣的同學(xué)可以聽一聽，或者給周圍的新人宣傳宣傳，先謝了！

總結(jié)

以上是生活随笔為你收集整理的EF和Dapper之争的关键的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。