最近在 phpchina 上看到一篇帖子，問到「大家習慣用原生sql語句還是用框架封裝的db類？
」。這裡所謂「原生 sql 語句」就是指手工書寫的 sql 語句，而不是框架自動生成的 sql 語句。
對於這個問題，有些開發者認為根據個人習慣選擇就行了。但是我認為這裡面實際上有個深層問題，那就是框架的設計思想對開發者的影響。
如果框架的資料庫服務僅僅是「簡化資料庫操作」，那麼使用原生 sql 就無所謂。因為用框架資料庫服務的核心思想就是用自動生成的 sql 語句來完成大部分常用的資料庫操作，從而達到簡化開發提高效率的目的。
遵循這種設計思想的框架，不管其資料庫功能有多麼強大，本質上仍然是圍繞「資料」提供服務。所以查詢的結果，顯然就是乙個個的陣列。即便提供了 activerecord 模式，也僅僅是陣列的簡單的封裝。
在這種框架中，資料是資料，邏輯是邏輯，兩者是分離的。就好像 fleaphp 的 tabledatagateway 功能強大，而且能夠自動處理關聯表資料。但歸根結底仍然是以簡化資料庫操作為目的來設計的，並不是要替代資料庫操作。
而 qeephp 則使用全功能的 activerecord 來實現完整的 orm 系統。所有的資料都轉變為了物件。資料轉變為物件後，資料和邏輯就封裝到了一起。這才是真正的物件導向設計。
此時，框架實際上提供了物件持久化服務和底層的資料庫服務兩個重要層次。
在這種框架中，如果使用原生 sql 就需要仔細考量一下。因為原生 sql 查詢出來的結果不是物件，所以無法利用封裝在資料之上的業務方法。
對於 cakephp、codeigniter、fleaphp、thinkphp、zend framework 這些框架，它們的資料庫服務的核心思想還是為「資料」服務，而不是為「物件」服務。這些框架的資料庫訪問服務，實際上是「加強版」的 adodb。再華麗的功能都只是為了簡化「資料」的操作。因此在這些框架裡面使用原生 sql 並不存在什麼問題。
如果是 symfony、qeephp 這樣提供完整 orm 能力的框架，框架的資料庫服務層僅僅是為物件持久化提供的基礎服務。框架是圍繞「物件」來設計和實現的。物件封裝了資料及其行為，應該盡可能使用框架提供的資料庫查詢服務。在這種框架中，開發者不應該以資料庫的角度來考慮問題，而是應該以物件的方式來思考。這和傳統的「資料庫為核心」的設計有本質區別。
所以，到底選擇原生 sql 還是框架自己的資料庫查詢功能，應該根據框架的特點和應用的需求來確定，而不是根據開發者的個人習慣來選擇，不然只能證明你選擇了不合適的框架。
由此可見，框架的設計思想顯著影響了開發者的解決問題的模式。並且對應用程式的設計和實現產生了實實在在的影響。
有興趣深入的朋友可以看看《領域驅動設計》和《企業應用架構模式》這兩本書，一定會有新的想法。
10個對開發者非常有用的設計原則
要點 我會盡力解釋jakob nielsen的10設計啟發式演算法。我會用例子告訴你，作為一名開發人員，如何使你的產品以及你產品背後的 更加有用。開發者也是設計師，他們只是使用不同的媒介。因此，你知道如何設計系統也是你的最終產品的一部分。關注於把底層設計的更加有用將會幫助確定以下事情 當我與開發者一...
雲計算系統中對開發者的API設計問題
本文講的是雲計算系統中對開發者的api設計問題，it168 資訊 近年來，隨著網際網路應用的普及與深化，網路資訊與服務趨於海量，使用者體驗需求不斷增長，資料海量 分布異構 處理複雜 使用繁瑣等問題逐漸突顯，旨在解決這些問題的雲計算 cloud computing 相關技術得到了迅猛發展。雲計算概念的...
對開發者來說，沒有比現在更好的時代
到處都有各種開源軟體，學習資源和有用的網路服務，我們可以學會新的語言，得到幫助，和他人協同，如果你的點子很不錯，還會有很多vc在等著給你錢幫你開公司，做產品。這並不是說我們的工作會很簡單，其實標準依然很高。不過提供給我們的資源和機會能夠讓我們走得更快，開發出更多的程式。創新的本質意味著我們光有點子是...