為什麼在代碼中不應該混雜sql語句?

01-28

問題產生背景:公司使用yii框架,組長說不應該在代碼中混雜sql語句。對此我不理解。
原因如下:
1.如果是安全問題的話，使用bindvalue就好了嘍。而框架本質上也是產生sql語句。

2.寫代碼過程中，我使用原生sql語句感覺靈活易用。若使用模型的話，數據結構稍微修改一下，那簡直就是噩夢。
組長來自騰訊,說在原公司是不能在代碼中出現，以yii框架為例子，不應該出現
$user = Yii::app()-&>db-&>createCommand() -&>select(id, username, profile) -&>from(tbl_user u) -&>join(tbl_profile p, u.id=p.user_id) -&>where(id=:id, array(:id=&>$id)) -&>queryRow(); 而只應該使用
model()-&>find("member_code=$userId");類似寫法。在yii框架官網上也有類似話語 -------以下內容是yii框架原文--------- 但很可能我們會花費 90% 的時間以編寫一些執行普通 CRUD（create, read, update 和 delete）操作的 SQL 語句。而且我們的代碼中混雜了SQL語句時也會變得難以維護。 -------以上內容是yii框架原文--------- 為什麼呢?我感覺不到哪裡難以維護呢,甚至覺得混雜sql語句快速靈活。求大牛指點

因為很多選型的人以為用了ORM就可以隨便切換資料庫了，其實並不是如此。大部分情況是根本不會換資料庫。

容易維護？對於一個成千上萬個sql語句的系統，如果需要從mysql遷移到oracle，我估計整個工作的工作量跟重新寫一個系統差不多了，不同資料庫的sql有較大的區別，就拿我感觸最深的就是分頁語句，mysql的是limit，這語句非常簡單，但是在oracle和sqlserver就沒有這麼簡單了,他們通常需要幾條sql嵌套才能分頁，改起來就沒這麼簡單了。

先說一條，題主的組長

而只應該使用
model()-&>find("member_code=$userId");類似寫法。

這首先是個錯誤，這裡這樣用是要被sql注入的，正確的寫法是

model()-&>find(member_code=:userId, array(:userId=&>10));

其實LZ可以想想我們為什麼要用orm而不是sql進行常用的crud

首先還是簡單啊！model-&>find()比起query build的寫法就簡潔很多，而且Yii 的model提供了很多額外的功能，鉤子函數。afterFind，afterSave，驗證功能等等。都是挺好用的。如果沒有這些，那你組裝實體的時候要做很多額外的事情。

除了簡單以為，用yii里的model還利於重構，比如一個很簡單的例子，你的member_code屬性如果改名為membercode，那用ide的重構直接改引用改名就好，如果你是寫死成sql的欄位名，那你就比較悲慘，只能替換字元串，萬一你前端的參數也叫這個名字，萬一你構建dto實體也有這個名字？

根據二八原則，orm是用來解決常用的crud，而sql是用來解決複雜的語句。實體model帶來的擴展性是sql沒法提供的，但是很多複雜語句用model寫起來又非常蛋疼，所以該用什麼的時候用什麼。

另外，難道題主沒用yii的model寫過後台？gridview插件那種配置的寫法用sql沒法做的。model帶來的前端驗證用sql你也享受不到。Yii或者他模仿的Rails都是一種全棧式的框架，為了能夠更好的減輕開發者的工作量，往往m端能夠很好的配合v端和c端，更方便的使用，這個具體看看文檔部分就知道。

除了各種省時省力以為還有一個很重要的原因，或者是最重要的原因就是關於企業架構模式，按照Martin Fowler的《企業架構模式》里的分類方法，題主的做法只能做成事務腳本模式，而建模成實體模型能帶來很多好處，比如可能可以應用上設計模式的知識，代碼的復用率也更高，模型的表達能力更強。具體見《企業架構模式》。還有也推薦題主看看《領域驅動設計》。當然怎麼只用領域模型還有很多爭論，具體題主還可以去ITeye論壇上看看一些老的精華帖，好幾年前就一直在爭論。

Yii至少1.X時代（2.0沒關注）的Aactive Record，query build其實在我看來實現的比較差，API各種不美觀，代碼細節也是各種難看，題主也可以跳開PHP的視野，看看這些框架抄襲AR的源頭Rails，然後看看Java那裡hibernate，會有更多的了解。

sql語句都要清清楚楚，這樣項目大才好維護

如果你們一定肯定要用一個資料庫而且要發揮這個資料庫100%的特點那寫sql也情有可原

否則還是用ORM吧

如果這條查詢是多處復用的封裝起來以後有調整的時候修改一處即可

非上述情況下其他情況這麼要求對我而言就是為了規範而規範這是風格的問題了