資料庫封裝類設計

再看別人一個程式的時候，發現他封裝的mysql操作類所有的方法都是static的，，而封裝的redis類的方法卻又都不是static的，請問下這樣設計有什麼特殊的意義或者有什麼特殊的考慮嗎？

回複內容：

再看別人一個程式的時候，發現他封裝的mysql操作類所有的方法都是static的，，而封裝的redis類的方法卻又都不是static的，請問下這樣設計有什麼特殊的意義或者有什麼特殊的考慮嗎？

沒辦法評價，他的選擇針對他的代碼使用的情境也許是適合的，比如有限的資料庫物件，且80%以上的請求都需要操作資料庫，這樣他可以在進程初始化的時候就啟動資料庫連接，而較少使用redis，而且又有多個redis對象，這樣的話如果總是把所有的redis在初始化的時候構造明顯就造成了浪費。所以他做了這種選擇。

建議學會思考，也要學會學習。
1- 作者寫代碼時的思路別人只能猜測，不會全中；
2- 不要認為你寫不出來，別人寫出來，那人家寫的就是絕對正確的、優秀的；
3- 先自己答題，再參考別人的答案，千萬不要被別人的思想先入為主；
4- 越大的項目出現爛代碼的幾率就越高，要去其糟粕，因為不可能一個人完成所有開發，而且就算一個人開發也有巔峰和低穀，設計的思路很好，具體編程時由於各種原因無法達到預期是太平常的事情。

回到問題本身，從我個人的經驗（以及很多架構）來看，static方法通常都屬於工具方法，如DB::factory, App::getModel, Date::format，而對於資料庫操作和redis操作，它們明顯不屬於工具方法，所以不建議靜態化。
而對於mysql類所有方法都是static的，從大方向來說其實是敗筆。開發人員不太可能在DB::insert方法內部進行資料庫連接狀態檢測，所以必然早就串連了資料庫，一方面如果當前進程完全不需要資料庫介入，這次串連就浪費了，另一方面，這明顯延長了資料庫連接時間，即如果是遲綁定，本次資料庫連接可能只要持續0.05s，而由於預綁定，實際上本次資料庫連接持續了0.1s，且其中的0.05s是閒置，在等待php進程處理其他邏輯，這兩方面都增加了資料庫壓力。

--補充--
如果真的在DB::insert中包含了資料庫連接狀態檢測，一方面增加了額外的邏輯，另一方面不適合多資料庫的項目（如果想相容多資料庫，那麼在調用insert的時候還要允許傳入資料庫連接參數，好麻煩）

個人看法，僅供參考。

首先，static的執行效率高，因為指令碼運行時就載入到了記憶體中，而new的話還需要執行個體化的過程，接著mysql因為sql語句相比較redis的操作方法要複雜，對於mysql封裝的方法可能比較複雜，而redis的動作陳述式比較簡單，作者可能懶得進行複雜的封裝。

