drupal對比thinkphp看國內開源環境的示例分析

這篇文章將為大家詳細講解有關drupal對比thinkphp看國內開源環境的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

對比ThinkPHP和Drupal看中外軟件業現狀

將ThinkPHP和Drupal（翻譯成中文為“水滴”的意思）放在一起聊會讓很多開發者感到好奇，但從中外軟件生態發展來看，這真的是一個好的討論起點，本文對這兩系統在各方面都做了一些對比，但對比不是寫作本文的主要目的，主要是分享中外軟件行業的不同，以及由此引發的一些思考，幫助開發者規劃職業生涯，為IT決策者提供決策依據。

這兩系統都是開源、免費的PHP應用，首先做個簡要介紹：

ThinkPHP：

產品定位：PHP開發框架，開發者在此基礎上繼續開發搭建自己的應用系統

開發機構：由國內“上海頂想信息科技有限公司”開發

創始人：劉晨，沒有太多資料，百度查詢為開源軟件資深顧問，資深PHP程序員，看云CEO，超過15年的互聯網產品開發和管理經驗，主要研究領域包括Web應用架構和開發，產品用戶體驗設計，致力于國內的開源事業

發展時間：最早誕生于2006年初

開源協議： Apache 2

官網地址：http://www.thinkyisu.com/

用戶群體：中國國內小微企業，在國內開發者圈中具有較高知名度，其官網自我描述為“是國內最有影響力的PHP框架和先驅者！”

著名案例：56群組、聯想問吧、中青旅開心遨游、寶礦力水特、星巴克、美特斯邦威的邦購商城、TCL的在線商城、新浪微壇，澳星、中車友科技等

團隊規模：沒有官方數據，但框架的每個文件有作者信息，據此統計一共有7人，其中主要開發者有兩人（貢獻90%以上代碼），這些數據不包括社區生態圈的貢獻開發者，依據企查查平臺對頂想公司查詢結果顯示，公司規模小于50人，參保人數3人

系統文件：按目前的6.0.7版本算，初裝文件數569個，占用空間2.41MB

Drupal：

產品定位：完整的后端系統（后端數據與控制中心），用于APP、小程序、網站、物聯網等的后端開發

開發機構：全球兩百多個國家共建，Drupal基金會組織的非盈利開源社區

創始人：最初由比利時的Dries Buytaert博士發起，Dries 2008年的大學博士論文是《Java應用程序性能分析和優化分析技術》，Java的發明者詹姆斯·高斯林(James Gosling)是其博士答辯委員會的成員，Dries個人主頁地址https://dri.es/about

發展時間：最早誕生于2000年

開源協議：GPL 2.0

官網地址：https://www.Drupal.org/

用戶群體：全球各國的企業、政府機構、大學、個人等，其中世界五百強企業市場占有率超過80%，著名IDE:phpstorm直接集成了Drupal項目新建

著名案例：國內有：華為、京東、百度、騰訊、清華、北大、貴州市政府站群、真功夫等，國外有：特斯拉、谷歌、本田、高通、聯合國、歐盟、哈佛大學、麻省理工大學、迪士尼、NASA、輝瑞制藥等

團隊規模：

擁有全球最大最活躍的開源社區，核心開發者1800余人，處于活躍狀態的貢獻者（代碼、文檔、設計等人員）共有超過12萬人，其中中國分社區兩千余人，主力推動公司Acquia雇員超過1100人。當前平均每周產生1300次左右代碼提交。

系統文件：按目前的9.1.7版本算，初裝文件數18770個，占用空間71.2MB

為什么是ThinkPHP和 Drupal：

一個是中國國內的流行框架，一個是國際流行的完整后端系統（也是目前世界上最強大靈活的系統，沒有之一），從它們的體量看這完全不在一個重量級，從其市場定位看，也沒有比較的意義，但探索它們對了解中外軟件生態具有重要意義，此外如果直接告訴你ThinkPHP能做的事情，Drupal都能做，而且還更加優雅和簡潔呢？事情是不是就變的很有意思了，繼續。

通常使用Drupal的國內開發者都是有很多年經驗的開發老手，是伴隨時代從各種系統一步一步淌出來的，他們一定知道或多少了解ThinkPHP，但使用ThinkPHP的開發者卻不一定了解Drupal，使用ThinkPHP的開發者選擇ThinkPHP的理由一般是：框架較底層PHP進一步的提供了常用基礎，靈活自由，和對帝國CMS這樣的系統進行二次開發相比，不受限制，能夠隨意實現自己的功能，但是在Drupal面前，事情就變的不一樣了，可能會讓開發者有如獲至寶的感覺，在此需要先簡要介紹一下Drupal的系統架構，整個Drupal系統是分層建設的：

最底層：

是框架層，基于流行的Symfony框架，Symfony可謂是PHP的行業標準，是世界最著名的框架，另一個著名的PHP框架Laravel本身很多部分也都是基于或來自Symfony，懂得Symfony框架的開發者可以很快上手開發Drupal，Symfony框架的作者法比安是一個傳奇人物，其另一個廣為人知的作品是Twig模板引擎，該引擎也用在Drupal中，Drupal是Symfony最著名的案例，其官網將Drupal列在第一位，Drupal社區也參與Symfony的代碼貢獻。

第二層：

是數據層，以實體為代表，向上提供各種數據，數據庫封裝即屬于該層，ORM概念以及ThinkPHP中的模型概念類似于實體概念在很早很早時期的樣子

第三層：

應用層，開發者在這一層處理各種業務邏輯

這里需要注意開發者在使用Drupal時，不一定要一層一層往下調用，而是可以跨越，直接去面向某一層，所以當直接面向框架層開發時，就可以將整個系統當做框架來使用，就像ThinkPHP開發者直接使用ThinkPHP框架一樣，這就是為什么說ThinkPHP能做的Drupal都能做的原因，所不同的是Drupal采用Symfony框架，題外話ThinkPHP深受Symfony影響，甚至直接采用了其部分組件，許多方面高度借鑒了Symfony框架（任何創造者都值得尊敬，因此不用“抄襲”這個詞，而用“借鑒”），主干流程幾乎相同，但在成熟度和細節上相差甚遠，這種差距舉個例子來形象的說明：

當人類先祖在結繩計數的那個時代，一個果子就是一個果子，一條魚就是一條魚，當從一個個具體事物中抽象出背后的數字“1”時，人類就面臨了一次巨大的飛躍，此刻的意義不亞于火的使用，進而發明數字、數學等，在時間和空間上，人類一直處于對世界的不停探索、抽象之中，無數次累積才有了今天的文明，可以說抽象程度越高，意味著越強，越直達本質。

許多偉大的作品都需要巨大的人力和時間去積累，那么ThinkPHP和Symfony之間，或者說ThinkPHP和Drupal之間積累的差距有多大呢？這里可以直接果斷的告訴你是小學和大學之間的差距，中間還隔著初中、高中，主要原因在于社區規模、生態和時間上。ThinkPHP和Symfony同為框架，是最直接的競爭者，ThinkPHP要有存在的必要就需要一條自主創新的路，卻又大量借鑒Symfony，這是一件非常尷尬的事情，作為開發者為什么不直接使用Symfony呢？同級別的CI框架（CodeIgniter）就完全自主發展，在許多全球排名中都看不到ThinkPHP的影子，但在國內，你可以在很多招聘信息中看到ThinkPHP的影子，這是個很奇特的現象，因為ThinkPHP是一個十足的地方性產品，連注釋文檔都是中文，本文也正是基于此才選擇了ThinkPHP來作為研究中外軟件狀態的起點。

何為好系統？我們需要什么？

俗話說工欲善其事必先利其器，這里列出幾個點來說明一個優秀的系統應該具備什么特性，下文我們將以此來對比ThinkPHP和Drupal：

完備性：

所謂完備性你可以認為是某個工具或組件被設計出來已經充分考慮到了所有的情況，比如PHP原生提供的字符串截取函數會把UTF-8字符截斷，產生亂碼，而你設計了一個截取函數，不但不會這樣，還不會截斷英文單詞，還考慮到了不截斷HTML中的標簽，那么你這個工具就比PHP原生函數更加完備，一旦發現有滿足不了的用列就需要改進以提高完備性，Drupal很多地方的設計是“完備”的，盡管Drupal也在持續探索和進化，但這種完備程度遠超ThinkPHP，舉個例子，Drupal的路由系統可以天然支持基于域名、協議、HTTP方法、數據格式、選項等進行路由，在都匹配的情況下有優先級分級，而這些是ThinkPHP不完全具備的，這種組件設計上的完備依賴于對事務本質認知的深度和大量開發經驗，完備性讓人類站在前人的基礎上繼續前行。

標準化：

標準化是大規模協作的前提，系統分層結構、跨系統通訊、解耦組件等都離不開標準化，Drupal完全面向RFC文檔，而不是自成體系，在注釋或討論中經常看到對RFC的引用，RFC文檔是IT互聯網的基石，類似在產品上常見的國家標準，常被用戶忽略，但又異常重要。

完整性：

合作分工，當把發展的足夠完備的組件湊到一起，大家都來使用它們，這就構成了完整性，然后人們不必自己再重復造輪子，突破內卷，完整性也會反過來促使完備性的提高，Symfony和Drupal就以組件和模塊的方式來解決完整性問題。

低耦合性：

系統設計各組件間需要盡可能解耦，這樣就能給各組件更多的發展提高的空間，不好的組件也便于替換，Drupal采用模塊化設計，連核心都是模塊化的，用戶可以在用戶空間中替換任何核心文件，而不直接修改，避免功能不足和阻礙升級，相對而言ThinkPHP耦合較緊。

掌握邊界：

一個好的系統勢必是分寸拿捏得當的系統，但這真的有點難，且仁者見仁智者見智，總的來看大方向或者主干系統必須是簡潔的，這里舉一個例子，在ThinkPHP中支持按路由參數決定路由控制器，即：Route::get(':action/blog/:id', 'Blog/:action');，而Drupal不允許這樣做，實現類似功能時通常采用代理控制器實現，簡而言之即該效果不應該在路由層面實現，而應該在控制器層面實現，這樣使得路由系統更加簡潔，系統架構更加清晰，這種思想貫穿Drupal，使得Drupal系統主干十分簡單干凈，當你要某個細化功能時，首先進入對應大支流再進入到不同的細化支流當中，是不是像一顆樹？但你更喜歡哪種方式呢？

簡潔性：

大道至簡，系統需要流程清晰，調用統一，規則一致，不允許有另外，或盡量避免另外，這樣的好處是易于新人學習，并且追蹤、排查都很方便。

生命力：

系統的生命力也在于可持續性，生態圈和開發者就是系統的養料，下文還會講到，這里略過。

對比ThinkPHP和Drupal：

ThinkPHP和Drupal相比總的來說，在于ThinkPHP抽象程度不足，積累不足，這是根本上的不足，它像一個孩子，Drupal是一個經歷歲月的成年人，懂得更多，知道事物背后蘊含的通用道理，做的也更進一步，假設我們是在建造一棟大廈，ThinkPHP提供了混凝土、磚塊、鋼筋等等建筑基礎材料，開發者需要去探索如何修建，如何設計等建筑學問題，而Drupal不但提供了基礎材料，還附帶了施工隊和設計院，很多時候你只需要說出你要什么樣感覺和功能的大廈就行了（你遇到的需求，通常已經有人遇到過，形成了數量龐大的貢獻模塊，安裝即可），當然如果你有興趣，你也可以參與修建的過程得到你自定義的結果。

本章在技術架構層面上來對比二者，如果你不是開發者，或者對具體技術不感興趣，可以直接跳過本章，接著看下一章，這里都以當前各自最新的版本ThinkPHP 6.0.7和Drupal 9.1.7，由于篇幅有限，僅選擇部分重要內容進行對比：

事件：

在ThinkPHP中將事件定位為替代原來的行為和Hook機制，由此可見作者并沒有認識到事件和鉤子之間的本質區別，相同點都是用第三方代碼來介入當前邏輯的處理，但在這個大前提下鉤子重參與，事件重通知，它們在數量和性質上都有很大不同，ThinkPHP將其混為一談，而Drupal認識的更加本質，由于ThinkPHP對“事件”概念的認識不足也導致實現上松散復雜，且功能上有重大不足，比如ThinkPHP事件沒有優先級概念，這在有順序要求的情況下至關重要，同時也沒有事件傳播終止機制，又比如ThinkPHP可以不要求實現事件類，實際上要處理事件通常必須要有參數傳遞，且需要將處理結果反饋給事件發源地，因此事件類是必須的，ThinkPHP非常初淺，而Drupal中統一采用事件派發器服務處理所有事件，對訂閱器和偵聽器也無特殊限制，在系統任何地方處理事件相關邏輯只需要面對事件派發器服務即可

中間件：

在ThinkPHP和Drupal中都有“中間件”概念，但二者定位有很大不同，在ThinkPHP里中間件實現的功能，在Drupal中是由事件派發器負責的，比如ThinkPHP文檔提到中間件主要用于攔截或過濾應用的HTTP請求，這在Drupal中是派發請求事件做的事情，此外還有路由中間件、控制器中間件都是如此，它們對應路由事件、控制器事件，而Drupal中的中間件主要作用是將HTTP處理核心由一個變成多個，在邏輯架構上Drupal要比ThinkPHP優雅和清晰很多，這也是ThinkPHP對事件機制理解不足導致的，這讓系統結構雜亂了，為將來的升級埋下了包袱

入口文件：

兩者的入口文件都很簡單，邏輯也比較類似，區別主要有三點：

1、Drupal直接在入口文件中向處理核心注入請求對象，從字面上直接體現“任何web系統都是將請求轉化為響應的系統”這一理念，而ThinkPHP的HTTP服務的run方法雖然也可以，但沒有在入口處體現，但這點沒什么本質區別，區別大的是ThinkPHP缺乏對“子請求”功能的支持，即系統運行過程中向自己再提交請求進行處理的能力，不需要跳出系統再回來，該功能對系統架構影響很大（貫穿整個體系，子請求除不能影響到主請求的環境狀態外還要考慮性能），此一點最能看出Drupal的系統架構比ThinkPHP強大太多，完備性高出不少，Drupal更能應對復雜的業務邏輯

2、真正的大道至簡，Drupal全局只有一個入口文件，不管是多應用，還是單應用的前后臺等，都只有一個入口，雖然用戶可以設置多個，但并不推薦多個，這減少復雜性保持簡單，且為URL別名系統打下基礎，而ThinkPHP有復雜的多入口機制，在多應用時尤其如此，這也對URL別名的支持會較困難

3、Drupal在初始狀態下將類加載器傳遞到處理核心中，這就天然支持替換或修改類加載器，而ThinkPHP不支持，它只是加載而已，當需要修改類加載器時，無法獲取，這一點導致靈活性大打折扣，比如很多類不能替換為用戶自己的，比如你要替換“\think\Http”類就比較麻煩。

多應用：

兩者都支持多應用，即多個系統復用同一套代碼，但具體做法上Drupal要簡潔的多

面向接口編程：

在ThinkPHP的很多實現中，對類沒有提取出接口，甚至有些重要類也沒有接口，比如：

\think\App

\think\Request

它們是如此核心和重要，但都沒有自己的獨立接口，ThinkPHP不是嚴格按照接口編程的，在靈活性上大打折扣，比如我想實現一個自己的app類去替換\think\App就做不到了，只能去修改核心，這樣每次升級是個問題，而在Drupal中是嚴格按照接口的，架構上完全面向接口，參數類型約束全部是接口，我們可以替換核心提供的任何類，而不必修改核心，包括最為重要的HTTP核心類：DrupalKernel，該類類似ThinkPHP的app類。

不嚴格按照接口編程除影響擴展性外，還有諸多其他壞處，比如對IDE不友好，文檔提取自動化難，代碼注釋無繼承，協作討論不方便等等

路由系統：

引用ThinkPHP官方教程的一句原文：

“ThinkPHP并非強制使用路由，如果沒有定義路由，則可以直接使用“控制器/操作”的方式訪問”

可見框架作者對路由的本質認識不足，如前文所述尚未抽象出數字1來，所說的“控制器/操作”的方式也應屬于默認路由或者內部路徑路由，而不是不用路由，看似無傷大雅的一點其實很重要，涉及本質認知，進而導致行為很不一樣。

路由是進入系統后的分岔路口，必定存在，許多業務邏輯都需要在這里處理，比如權限控制、參數轉化、路徑別名處理、語言處理等等，在ThinkPHP中認為可以沒有路由，這導致了另外，這樣的認知結果勢必將事情變的松散和復雜，比如代碼冗余、使用不統一等。

而入口處理只是路由的兩大功能之一，另一大功能是出口處理，也就是全系統URL的生成，這對URL別名處理、語言協商、SEO等至關重要，但ThinkPHP中只有簡單的實現，尚未充分認識到路由系統的該責任，比如這里提出一個需求：

用戶在一個自定義函數中給全系統的URL加上“target="_blank"”怎么實現？

容器與依賴注入：

該概念和叫法起源于Symfony框架，詳見：

https://symfony.com/doc/current/components/dependency_injection.html

簡而言之其主要思想是在系統中設置一個中央大對象，也可以叫做母對象，其負責收集、保存、自動實例化我們常用的對象，在Symfony中，這個大對象稱為容器，其中保存的對象稱為服務，服務的定義可以采用YAML靜態提供或服務提供器方式動態提供，“定義”具備一定的格式，當我們需要某服務時，容器對象會依據定義去實例化服務對象，然后保存并返回，定義中涉及類、參數、工廠方法、實例化后回調、配置器、公私有屬性、特征繼承、延遲實例化等概念，容器形成前還會有服務編譯過程，以便處理服務組群、參數修改等高級功能，在容器中每一個服務都有一個ID，稱為服務ID，在使用之處通過該ID取得服務對象，容器中除了保存服務外還保存容器參數、服務別名等。

ThinkPHP的容器概念有Symfony的影子，但還非常幼小和初級，其實現離大道至簡相去甚遠，較混亂，比如沒有明確的服務ID概念，在Symfony容器里的服務對象，必有對應的服務ID，而ThinkPHP將類似概念稱為abstract，其可以是標識符或者類名，但部分容器方法又將其視為類名使用，比如：

\think\App::register

\think\App::getService

看起來作者是想盡可能靈活，但卻導致了由不統一引發的混亂，在ThinkPHP中“服務”概念有單獨的定義（有點像操作系統的服務），但本質上還是Symfony服務，只是進行了特殊處理，在Symfony中將服務放到容器里面叫做對服務進行“收集”，或者叫“注入”到容器，而ThinkPHP稱為將服務“綁定”到容器，顧名思義容器就是用來裝東西的，為什么要叫綁定呢？這種叫法非常拗口，還有很多名字也詞不達意，比如運行容器中對象的實例化后操作，ThinkPHP稱為“執行后”操作，而不叫“實例化后”操作，計算機界有句名言：“什么難？緩存和命名”，在這一塊上ThinkPHP需要改進，現在的一些命名對新手不友好。

另外服務（在ThinkPHP中應該稱為綁定到容器中的類、對象或回調才對）又可以向容器綁定服務這個特性看起來靈活，但是對代碼追蹤和調試非常不友好，增加新人接手系統的難度，而Drupal得益于模塊化設計，使得可以做到集中聲明（因為模塊必定知道服務會依賴哪些服務，通過容器編譯機制也可以判斷某服務是否存在），這樣在追蹤代碼和調試時就做到了盡可能簡單，導出運行時容器中的服務定義也很方便，不用真的去實例化每個服務。

門面Fa?ade：

這只是ThinkPHP中的概念，用來以靜態方式調用被包裝類的動態方法，即用靜態方式代理類到方法級別，這只是形式上的調整，內部依然需要實例化對象，其實該概念并沒有存在的必要，不但對IDE十分不友好還違背了PHP靜態方法設計初衷，只是彌補了ThinkPHP中容器功能的不足，在Drupal中無此概念，其功能目的是統一采用\Drupal::service($id)靜態方法獲取服務實例，進而由開發者自行調用其動態方法，如需不同實例則自行克隆，這也避免了use引入代理類的麻煩。

助手函數

ThinkPHP中有個助手函數的概念，文檔提到其目的是享受IDE自動提醒的便利，這相當于Drupal中的“\Drupal”全局類提供的靜態方法，或者快捷函數，但Drupal并不是因為IDE，而是更加便捷的獲取服務，因為PHP函數或靜態類方法是超全局可用的。

控制器和模型：

在ThinkPHP中認為控制器是用來做業務處理前邏輯的，必須是一個php類或閉包，業務邏輯是“模式器”的事情，其實這是很僵化教條的一點，首先控制器可以是任何形式表示的php回調，包括函數、容器實例的方法（用容器ID進行定義）等，其次現實中業務邏輯的邊界并沒有那么清晰，很難抽象出“模式”然后還能給出這個名字，再次控制器應該已經是業務處理的開始，而ThinkPHP概念中的控制器所做的事情應該是在路由中處理，這一點ThinkPHP已經意識到了，并在文檔中一筆帶過。

多語言處理：

在實現上ThinkPHP和Drupal都是基于英語作為開發元語言，ThinkPHP的翻譯實現非常簡陋，在現實中通常不能滿足需求，開發國際化應用時尤其如此（這應是應用范圍覆蓋不足導致的），Drupal具備完整的多語言系統，已經完整處理以下概念：

語言單復數問題（部分語言還不止單復數）上下文問題（“may”翻譯成“可以”還是“五月”呢？）JS里面文字的翻譯界面、配置和內容語言的翻譯團隊翻譯協作機制向左文字語種的處理等等

而這些ThinkPHP都不具備，僅簡單的實現了模板里面文字的翻譯，語句中變量的替換；此外Drupal天然具備多種語言協商機制，如用戶設置、URL前綴、會話信息、域名、HTTP頭、用戶代理標識等等，支持通過插件自定義語言協商機制，在ThinkPHP中默認僅支持URL、HTTP頭變量、cookie、瀏覽器，注意如果你以Cookie來傳遞語言信息，在開發國際系統時可能會遇到法律問題，很多國家要求系統明確提問用戶是否能夠使用其Cookie；綜上使用ThinkPHP時需要開發者自行解決大多數語言問題，但實際上多語言系統貫穿整個系統，非常龐大復雜，Drupal由于是國際共建的系統，多語言是其一大亮點，是天然的多語言系統，只此一項就可能難住ThinkPHP開發者。

緩存系統：

完整的緩存系統有三要素：超期時間、失效標簽、上下文，Drupal對其有完整實現，而ThinkPHP只實現了時間和標簽，沒有實現上下文，何為上下文呢？簡單的說它指示同一個緩存鍵KEY下，被緩存物屬于誰在何種環境條件下進行的緩存，比如用戶的權限、登錄狀態、語言、ip、協議版本、主題信息等都屬于緩存上下文，同一個KEY在不同上下文條件下需要讀取不同的緩存物，這對大型系統設計至關重要，且該系統非常龐大，ThinkPHP需要開發者自行解決緩存上下文的問題，此外ThinkPHP未提供緩存合并機制，這將無法實現緩存的分層分級處理，要實現高效緩存，該功能是必不可少的。

會話Session：

使用ThinkPHP的開發者得自己解決會話相關問題了，為什么呢？IT發展到今天，僅小微系統只使用一臺服務器，大多數系統都會負載均衡到多臺服務器上，因此應用必須要求無狀態，那么會話數據就不能存儲在本機，通常的解決辦法是存儲到數據庫中，基于此，由于ThinkPHP是一個框架無法提供數據庫儲存會話的現存方案，因此需要開發者自行處理，而Drupal本身已經考慮到負載均衡、應用無狀態等事情，會話默認已經儲存到數據庫，可以開箱即用，盡管ThinkPHP提供了擴展能力，開發者還是要付出許多人力成本去實現開發

在ThinkPHP的會話實現中有個問題：會話的保存不在腳本結束之后進行，而是在腳本里面執行，這樣當用戶調用die或exit就會導致無法保存，應當注冊關機函數才對，詳見php函數：

register_shutdown_function

數據庫：

ThinkPHP和Drupal都支持多數據庫，該特性在ThinkPHP中自創了一個“分布式數據庫”的概念來描述，Drupal沒有專門渲染概念，只用業務標識對不同數據庫進行區分，二者也都支持主從配置和讀寫分離；但在實現上很明顯Drupal優雅很多，比如在數據庫配置的數據結構上，Drupal采用一個多維數組，第一級鍵名是業務標識，第二級鍵名是主從標識，其值就是連接配置信息，這樣的結構十分簡單，如果你要實現一個數據庫負載調度子系統，那么該結構的接口是非常簡單的，而ThinkPHP的配置數據結構中，把所有的主機地址儲存在一個數組鍵下，把所有的密碼儲存在另外一個數組鍵下，等等諸如此類的還有用戶名等，這樣的結構在生成連接信息時還需要再次解析配置信息，不但閱讀修改不直觀還消耗了系統性能，數據庫負載調度子系統的接口也較復雜，非常不優雅。

二者也都支持多類型數據庫，Drupal核心自帶對mysql、pgsql、sqlite三種數據庫的支持，加上社區模塊幾乎完整實現了對所有常用數據庫的支持，在底層，Drupal將不同數據庫的差異稱為“方言”，不同方言的處理在驅動層完成，向上層提供統一接口，換句話說上層數據庫操作類感知不到底層用的是什么數據庫，采用標準的SQL規范，這樣就完美屏蔽差異，實現了數據庫解耦，模塊開發者就不用去考慮用戶用的是什么數據庫，建表、查詢、修改等等全部是統一的，在應用層切換不同種類數據庫時可以做到一鍵搞定。

關于數據庫操作，Drupal由于是一個完整系統，已經默認實現了一整套非常先進的數據儲存結構，該結構提供了對系統數據層的支持，當所有人都基于統一數據結構時，奇妙的事情就產生了，分布在全球的人們可以合作實現豐富的上層應用，該結構造就了大名鼎鼎的實體概念，由此Drupal也提供了更多關于數據的操作，比如實體查詢，用戶實現了開箱即用， Drupal是包容的，用戶也可以定義自己的數據結構。

對數據層的支持ThinkPHP是無法做到的，ThinkPHP用模型來處理數據封裝和操作，模型和實體相比，是非常初期和幼小的概念，它能做的實體皆可做，反過來則不行，比如模型不支持輸入用的字段控件、輸出用的格式化器、表單和查看的顯示控制等等，究其原因，是因為這些都需要更高層面的實現。

中外開源生態與聯系：

在充分對比后，會明白ThinkPHP能做的Drupal都能做，而且做的更好，反過來卻不行，因為Drupal是一個完整后端系統，被人譽稱為WEB操作系統，已幫助做了更多的事情，常用需求基本都有了，開箱即用，ThinkPHP開發者想要那些功能，則需要在ThinkPHP基礎上走非常遠的路，先不提質量問題，單就時間消耗就是一個驚人的數字（比如Drupal 8正式版發布之前，其各種開發版，就由一千多名國際頂級開發者為此工作了五年），事實上很多Drupal開發者確實也不屑于去學習ThinkPHP或者是其他框架，但在國內可以發現一個很奇特的現象：為什么國內還有很多小公司在用ThinkPHP？（關于這一點，可以到各招聘平臺搜索PHP招聘信息就可略知一二），要解釋這一點有兩方面原因：

文化交流受阻：

中外文化、生活等的交流依然還只限于一小部分人，大部分人是沒有異國朋友的，主要原因是眾所周知的網絡屏障和語言問題，語言不通應該是主要原因，我國發展太快，目前國內開發者主力是70后到90后這一批人，絕大部分英語溝通水平欠佳，啞巴英語，或者閱讀困難，他們往往本能的不會去接觸英文資料，00后或者10后的英語水平則高很多（得益于教授早，互聯網等），在未來他們會更多融入國際環境，所幸的是現在科技發達，翻譯軟件水準越來越高，也越來越多人投身到技術引進上面來，比如Drupal在中國就有“Drupal中國”、“愛碼文檔匯”、“水滴間”、“Drupal大學”、“Think in Drupal”、“寧皓網”等等一大批技術平臺，這些平臺或博客提供了巨量、幾乎完整的中文文檔，掃平了語言障礙。在北上廣深、成都、南寧、寧波等等城市均有以Drupal作為核心技術的開發公司。

壓力下導致的快餐現象：

中國人絕對是世界上最勤勞的人群之一，這種勤勞很大程度上和壓力相關，住房、結婚、醫療、教育、養老每一個都是一座大山，“搞錢”必須是頭等重要的大事，對于大多數普通民眾來說，保持匠心做長線積累風險太大，缺乏安全感，眼下能搞的錢先搞了再說，社會發展那么快誰能知道以后什么樣子，這種現象對我國基礎科學領域傷害巨大，同樣的在快速發展的IT業更是如此，我國開發者身上的擔子太重了，996甚至被大公司推崇，長期做著CURD這樣簡單的碼農的工作，很多開發者根本沒有太多時間去學習，稍有時間得用來陪陪家人、孩子、女朋友，自己休息的時間很少，學習深究就更難了，如果有多余時間通常用來接私活搞外快，在這樣的大環境下，大家習慣于“吃快餐”，有鋤頭用就先用著，學習挖掘機沒有空，發展挖掘機更是成本高昂，最終導致了我國開源事業難以發展，為數不多的開源項目帶著濃濃的商業味，其中小公司靠廣告補貼，靠開源項目引流商業項目盈利（看看ThinkPHP的首頁就能感受到），大公司則出于培養后備人才、免費消除Bug等等而選擇開源，帶著濃厚的“勢力范圍”色彩，總的來說純粹的熱愛和興趣占比很小，但這不應責備中國的開發者們，這是重壓力的大環境所致，現在也出現了逃離一線城市的現象，許多人去到不那么繁忙，有些閑暇時間的二線城市，也許他們是開源的一種力量，得到APP（羅輯思維）也預測中國的創新中心可能會移動到那些擁有閑暇的二線城市。

相反國際開源的土壤好的多，由許多發達國家主導，而這些國家通常是福利型國家，相比壓力不大，人們靠興趣做事的空間很大，許多參與開源的人首要考慮的是人生意義，關于此有個“馬斯洛需求模型”讀者可以了解下，“喜歡”保證了“質量”，福利可以讓開發者不考慮年齡、工作，在一年一度的DrupalCon大會上，你可以看到很多開發者年齡都非常大，五六十歲的人很多，他們在一起眼中帶光的談論技術，將一生的積累注入到Drupal中。

當然國際開源也并非主要由發達國家參與，英語系的不發達國家也是重點參與者，他們往往是通過開源衍生的商業項目賺取外匯，典型國家就是印度，在印度兩極分化嚴重，曾經被英國殖民過，在其高端人群中英語普及率很高，這一點讓印度高度融入國際開源，相應的造就了印度較高的軟件開發實力。

開發者職業規劃：

這一節討論下國內開發者的職業規劃問題，在國內社會一直有一種聲音：“程序員是吃青春飯的”，對應的通常就是35歲門檻，你可能經常看到某某大公司辭退35歲的大齡開發者，一些公司招聘年齡要求不能超過35歲，很奇怪，35歲正是能力上積累較深，很多事情的分寸上拿捏得當的年紀，為什么會出現這個現象呢？我們來探索下：

首先那些新聞有很重的博眼球嫌疑，就像“女司機”一樣，實際上女司機的事故率比男司機還少，正是因為少所以才是新聞，才能讓你瀏覽，但這樣的新聞多了你會形成錯覺，因此35歲門檻一定程度上被過度渲染了，造成了不好的影響，甚至有些人無理由跟風。

但35歲門檻又有一些道理，這要選擇性區分，如果開發者一直做著CURD這樣簡單、重復性的體力活（真正的碼農），那么當達到35歲時，和剛出校門一兩年的年輕人比，競爭力可想而知，35歲時孩子上學、父母身體、住房等壓力會很大，逼迫開發者提出更高的待遇要求，家庭事務、應酬交際等也多，不愿加班，通常工齡長累加的工資相對更高，如果你做的事情年輕人也能做，老板選誰呢？同時年紀大了多少有些面子問題，如果上司是個比自己小很多的年輕人，是否服管呢？對于年輕人來說管理一個比自己年長很多的人有時也挺尷尬。根據這些可見35歲門檻的存在有一定的道理。

時間不等任何人，那么開發者如何避免35歲門檻，該如何規劃自己的一生呢？

如果你發現自己并不真的喜歡技術，那么你應該在年紀上還有競爭力時趁早轉型，跟隨內心，找到喜歡的事情并開始積累競爭力。

如果你真的很喜歡技術，并愿意且準備好以此度過一生，那么你就需要高效積累，不停學習，時刻注意拉開和年輕人的技術差距，他們有壓力小和體力強的優勢，你需要以技術優勢進行彌補，大神之路不是你可選可不選，而是必須選擇的，當到達35歲時，你必須是一個大神，擔起年輕人難以勝任的系統崗位。

這里需要提醒你隨著社會的發展，技術的門檻其實是在逐步提高的，比如你可能聽說過“全棧工程師”，但那只屬于互聯網時代初期，現在社會分工太細太深，已經不存在全棧了，如果存在那可以換個叫法“樣樣懂，門門差”，因為人的精力差距不會太大，你選擇研究全部，別人選擇鉆研一處，而用人單位是按崗位用人的，你需要考慮誰更有優勢，理智會讓你選擇深鉆一門，周邊懂得即可，但這樣你會成為一個大機器上的一個部件，你的選擇自由被限制，細分門檻要求會很精專，淺嘗輒止，不求精深必面臨淘汰。

做這樣的機器部件不適合有創業理想的人，那么創業會面臨些什么呢？看看中國社會的發展，所有通用的IT需求你可能都沒有機會，比如網站被公眾號取代，不多的網站市場也被SaaS平臺占領，與這樣的平臺競爭，他們只需要點鼠標初始化即可，你得寫代碼，他們按時間收費可以很低，你得一次性收費，站在客戶角度首要考慮的當然是成本問題，通用需求還包括電商系統、直播系統、內容付費系統等等，而這些都有很成熟的現存解決方案，在規模優勢上，微盟、有贊、微擎、微積木等等這些都是已經發展起來的很不錯的SaaS平臺，非通用的IT需求呢？會形成許多垂直領域的解決方案，山頭被搶占瓜分，比如美團、滴滴、土巴兔、頂呱呱等等，他們所在的領域你都很難再有機會，留給開發者的僅剩下數量不多的真正需要定制化的需求，這樣的需求有個特點，由于是定制，成本原因決定了客單價必須高，此時客戶會對創業者公司的實力有所要求，你有多少員工？有多大的辦公室？有多長時間的歷史積累？有多少案例？注冊資本有多高？

此外IT發展到今天，同一個應用系統在軟件形式上會呈現多種形式，通常需要App、小程序、網頁等中的一種或幾種，還涉及到跨平臺（APP有安卓、IOS和即將出現的鴻蒙，小程序涉及微信、支付寶、百度、抖音等等），雖然有UNIAPP這樣的工具，但在客戶要求原生應用時仍然所需技能很多，這就導致必須組建團隊，團隊成員還包括非技術人員等，比如業務員、財務等，這些都形成了一定的進入門檻，最終你會發現創業需要的不止是技術更多的是資金。

說到這里你是否感覺路很難？但請你相信不是只有IT領域是這樣的，有競爭的地方都會這樣，任何成功皆不容易，唯有你的興趣能保證你能走多遠、走多高，所以請跟隨自己的內心。

如果你跟隨內心，深思后依然選擇了做技術，當一個了不起的大神，那么你該怎么做呢？首先你必須要注重積累，尤其是要站在巨人的肩膀上向著未開發的土地猛沖，你需要找到所在細分領域最有前景的生態圈，加入進去，回到PHP開發框架上來，小白看框架它只是進一步封裝提供了要的功能，而大神看框架是它提供了一個統一的協作平臺，大家都在同一個平臺上進行創造，這樣才能避免自己重復造輪子，在經濟成本上才足夠劃算，借助眾人的力量才能騰出手來發展自己的事情。

基礎平臺的統一性非常重要，只有這樣人類才能累積向前，才能降低成本，但統一平臺的形成有個很有意思的規律，那就是最終只會剩一個作為主要平臺，然后有個處于第二位的平臺來形成競爭后備，第三第四位的基本可以忽略不計了，且第一位和第二位在體量上會選差很遠，這樣的列子有很多，比如歷史上有幾千個操作系統，最終剩下window和linux，二者用戶數量選差很遠，又比如安卓和蘋果、淘寶和京東、抖音和快手、美團和餓了么等等皆是如此，一旦格局形成，便很難撼動，比如微軟就撼不動安卓，不是因為技術，而是因為滾雪球效應在發揮作用，王者會更強、更大，敗者逐漸落寞消失，即便王者犯了些小錯發展也不可改變，比如現在我們使用的鍵盤，其字母排列其實不是最合理的，歷史上也出現過排布合理的鍵盤，但由于大家已經習慣于現在的鍵盤，所以也就延續使用了，要成為王者有兩點很重要：技術層面的先進性要足夠、社區生態要建立滾雪球效應，這兩點相輔相成。

那么在PHP框架領域誰會成為這個統一的基礎平臺呢？開源項目的主要發展力量應該是大批使用者在使用過程中不斷的提煉并總結，然后一起對其的持續討論并改進，而不是幾個人單憑自己的思考或經驗，因此如果在ThinkPHP和Symfony中做選擇，答案已經非常清楚，其實很早Symfony就意識到統一平臺的意義所在，因此致力于解耦的、完備的基礎組件的建立，并反復迭代，以至于現存其他一些框架也用Symfony的組件，比如Laravel和ThinkPHP，Symfony一再強調“標準”，且現在也已經存為php開發領域的事實標準，因為標準化就是統一平臺的必備條件。

至于Drupal則是在Symfony基礎上建立起來的更高一層的統一標準平臺，成為了完整系統的標準基礎，在這里常用的應用層功能幾乎都已被提供，人們正在此統一平臺上，基于模塊化設計，創建更多面向未來的功能，實現Drupal的理想“提供卓越的數字體驗”。

決策者技術選型：

如果你是一位創業老板，或項目總監，正為項目進行技術選型，那么這里為你提供幾個注意事項：

控制成本：

這似乎不用多說，理所當然，但你真的控制到了嗎？軟件是無形的，如果你不是專業人士，很難控制成本，這里說一些坑：

在目前環境下，想做個長遠規劃的項目，能自己開發，就不要外包，有些東西看起來一樣實則差距非常大，不專業的人很難看出健壯性、擴展性、安全性、持續性等等性質在兩個系統間有何不同，比如同樣功能的系統，負載五千和負載五千萬的開發成本是完全不同的，又比如軟件文檔工作量有時會遠高于軟件開發本身，文檔是保障系統長遠發展的重點，但外包很難做到文檔齊全，外包質量通常會讓你在日后買單，究其原因，不是因為外包公司實力不行，而是成本問題。

少欠技術債：

不要在開始因為省錢，找一些積累不夠的開發者，這里分享個故事：有位老板和技術總監在人才招聘上出現了分歧，技術總監要求給出崗位工資1.5萬，來了一個應聘者只要八千，技術總監不要，但老板大喜，認為賺到了，為什么要傻傻的多給錢呢？有時小白會在系統中留下巨大隱患，這位技術總監就是看到了技術債問題，開發團隊一定要有積累深的技術骨干來把控系統，同時在選擇基礎系統時不要選擇成熟度低的東西，這樣保證盡可能不欠技術債，否則你會開始輕車熟路，后面深陷泥潭，如果遇到商業關鍵窗口期，那么神仙也救不了你

借力加速：

社會發展到今天，其實很多IT系統功能都已經有了，而且非常齊全，你不需要自己去開發，比如要在ThinkPHP和Drupal之間選擇，我會毫不猶豫的選擇Drupal，因為ThinkPHP只是個半成品，通常在各種業務系統中有些功能是必須的，比如垃圾回收系統、狀態系統、鍵值儲存、批處理系統、計劃任務系統、數據類型化系統、Ajax系統、數據查看引擎、版本支持系統、權限系統等等，這些在ThinkPHP都沒有，而Drupal很完備，而要在ThinkPHP上開發出這些，需要數月到數年，不但談不上基礎統一平臺的優勢，也很難保證自己開發的代碼質量，不但白白浪費了資源，在后期新加成員還需要付出高昂的培訓費用，有現成的基礎齊全的、成熟的系統為什么不用呢？

融入大環境：

開發體系要融入大環境，除了借力加速外，還在于后備人才的獲取，讓開發者和項目解耦，不要因為在現有開發者離職或不夠時，找不到足夠的開發者快速加入項目，融入大環境，解耦開發者很大程度保障了項目的發展安全。

國家開源建議：

這一節我們站在國家層面，來看看應當如何對待開源，我國日漸強大，很多國人都期待著超越美國那一天早日到來，那么中國要突破美國封鎖，達到超越的目的，就必須要參與國際開源成為貢獻主力，而不是自己搞一套獨立的體系（自建體系應發生在新生事物上，比如下一代物聯網操作系統鴻蒙），因為開源是全人類的開源，而不是哪一個國家的開源，閉門造車出門不合轍，會讓中國遠離世界，要知道中國只有十四億人，而全世界有七十多億人，生態力量無法和全世界對抗，因此理性的做法是參與開源，努力做出奉獻，一則繼承已有的人類發展成果，站在巨人基礎上發展更快，二則選擇和大多數人在一起，開放國門，建立影響力，才有可能樹立大國形象。

關于“drupal對比thinkphp看國內開源環境的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。