架構的設計思想對開發者的影響

最近在 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 還是架構自己的資料庫查詢功能，應該根據架構的特點和應用的需求來确定，而不是根據開發者的個人習慣來選擇，不然隻能證明你選擇了不合适的架構。

由此可見，架構的設計思想顯著影響了開發者的解決問題的模式。并且對應用程式的設計和實作産生了實實在在的影響。

有興趣深入的朋友可以看看《領域驅動設計》和《企業應用架構模式》這兩本書，一定會有新的想法。