技術角度wordpress結構優缺點分析


我還是覺得自己開辟搭建一個獨立blog平台,我常用linux服務器,因此選擇php環境。 這樣,我可以選擇的開源博客系統會有很多。這里不對博客系統進行縱向對比。我說下,對wordpress認識過程,一些自己的體會。純屬代表個人意見,歡迎討論!


剛開始,下載一套wordpress 3.5,然后一路安裝下來,比較簡單,跟常見其它一些開源平台查不到。 只要配置好數據庫連接,然后一路下一步,分把鍾就可以做好。 也是由於,對wordpress 早已經有所耳聞,而且感覺它名氣很大,這類系統中佼佼者。

  • 首先看看它數據庫結構吧

image


11張表,實現了強大的博客功能,首先表示不簡單。現在很多cms 基本上都是40-50個表。其中很有幾張表,設計為窄表,基本上類似,類型,鍵值名,鍵值。類似近年的NoSql類型數據庫。都是鍵值對。讀取靈活,擴展方便。 可能就是,開發時候復雜些。這類基本設計是:posts,postmeta表,所有文章都具備的通用字段,就放到posts表,而針對文章進行屬性設置,如:訪問數,tag,權限等。都放到postmeta表。如:

image

窄表,可以任意對一篇文章新增鍵值,擴展新的屬性。 這也是wordpress 插件幾乎可以做到無所能一個原因。 這類表可以非常靈活。新增一個屬性,只需要在這個表里面,對posts ID 增加這類屬性的一條記錄。而且這類窄表,字段少,讀取速度也很快。

感覺到表設計不足之處(個人認為,歡迎交流)

image

Posts表里面字段,一張表里面,居然有6個text 字段。如果讀取時候,不小心select *,該會有多少磁盤IO,一條記錄,該會占多少的數據塊。記得剛剛,分析wordpress時候,當時一下子就看到這樣情況。我毅然選擇放棄該系統。也因此讓我忽略了,他窄表設計優點。 個人認為,一些字段可以設置為varchar,另外text 可以移到單獨posts_data表。里面只存放text字段,PostID 信息。歡迎高人指點。


  • 再看看它的代碼吧

現在wordpress插件有成百上千個,它基本上可以做各種系統。除了blog外,它還被改成了新聞網站,企業網站,電影網站,甚至是商城系統。這些足以說明,他前端程序一定有過人的設計架構,有它足夠靈活性。

  1. 看下他的目錄結構吧

image


從這些目錄,真的還沒有發現它比較獨特優越性。現在網上常見的MVC 結構,有獨立模版目錄。 這個wordpress,實際只能算,MC,而沒有V,它實際上前端是通過php 直接調用include 目錄里面函數而已。如:

image

這個也是它的一個獨特特點了,國內很多模版,都會開辟自己的標簽,如smarty的是:{$smarty.config.aa} 等。 而wordpress里面沒有自己標簽,要讀取,通過函數去讀。它省去了標簽省去了大家學習標簽成本,但大家也需要掌握N多的函數。 可以把它的函數,理解為其其它系統中定義標簽。

無論是函數,還是標簽,只要你在前端頁面都使用這些方法,去讀取你要的數據,實際上都對后端數據庫做了隔離。從而讓使用者不關系數據庫數據了。 數據庫結構修改,只要調用函數做相應跳轉。前端頁面還可以照樣那樣用。而不需要任何修改。從而保證它的穩定性。

image

它函數封裝,不光做到從DB讀取數據,通過函數,讀模版,讀公共包含文件,等等都做到了,函數封裝。幾乎做到了,所有讀取數據封裝(DB,file,request中),這樣封裝,在目前國內系統中很少見,因為為每個功能去寫一堆函數,切實很多工作量。國內框架,基本上喜歡封個方法,做到很通用,然后自己去調去吧。 這個方法,可能可以讀取用戶表,也可以讀評論,也可以讀文章。 其實,看起來很通用,實際用起來就會很復雜,也會增加上手難度。我們看看wordpress 設計方法。


image

這只是其中的很少一部分函數,真正差不多1000把個函數呢。 因為,wordpress 函數幾乎封裝了所有數據調用,因此前端開發只用調用函數,就可以完成。簡單容易,這也是靈活性,及得到廣泛使用一個原因。

2.  看看它代碼實現優點

如果說,wordpress 光只有,強大的含數據庫,做到前端頁面與數據直接分離。現在很多標簽調用也能做到分離。 真正wordpress靈活性,以及能夠擴展出各類插件,完成獨特開發功能,與它獨立系統分不開。

它有一個 消息機制,還有一個隊列過濾模塊,任務隊列處理模塊。這2個模塊,都建立在它的一個消息機制上,普通開發方式如下:

消息機制,可以做到,前端跟實現地方解耦。這里打個比方,如一個用戶完成注冊,我要給用戶發一個郵件,然后給管理員發一個站內信。我們以前做法是:

image

如果發完站內信后,還有發一個手機短信,我們必須修改注冊邏輯,在接下來再增加一個發送手機短信功能。 這時,你發現任何前端修改,都需要在原先邏輯里面修改一通。 如果我們采用消息機制,程序將變為:

image


這個圖,是改用消息模式結果,用戶注冊功能模塊,跟接收到消息處理各個任務直接,代碼沒有直接關聯。如果需要增加一個接收注冊消息,給其它人通知一下,只需要新增一個模塊,訂制注冊消息,然后處理一個新流程即可。

目前各類開源項目里面,消息機制已經變得非常常見了。 但在wordpress這個blog框架,它的消息主題非常完善。幾乎任何動作都有消息主題發送消息。 這樣讓開發者,只要訂制相關主題,就可以,增加自己額外處理功能。 例如: 用戶發一個帖子后。檢測下用戶是不是有廣告信息,只要訂制:發帖消息,然后,增加新功能,檢測內容。發現不滿足,直接屏蔽帖子。

有人估計要說,這類功能,現在很多框架有類似東西,例如,頁面開始有個start事件,結束有個end事件。 確實,消息概念在很多框架里面確實有用。 但是,沒有這么完畢的消息主題拋出。 幾乎做到整個系統任何操作,都能有消息,這樣沒有什么功能不能進行擴展了

有興趣可以去研究下,wordpress add_filter,apply_filters ,還有add_action,apply_action ,只是收到消息后,一個按順序進行一系列元內容過濾,一個是接收元內容,進行一系列任務。

wordpress 2大優點,一個是函數封裝數據操作,一個是它完善消息功能。那它有何種確定呢?

  • wordpress源碼不足


任何一個系統,有優點,一定有不盡人意的地方。

首先,因為它要做到自己很多函數,可以直接讀取一些循環數據。或者直接讀取數據庫配置項。它啟動時候,采用了大量的全局變量。一個大的blog,可能啟動后全局變量有幾百個。 有的是數據記錄,有的是字符串,有的是對象。你可能會發現,這些數據可能有1,2M;無論有沒有使用,這些都會先創建。可想而知,他將帶來大量內存浪費。另外一個就是,可能會影響調用速度。 很多網友使用wordpress就明顯有這個感覺了。

另外一個問題,其實正式來自它的消息處理模塊。 它跟我們網上看到的不一樣,它的消息模塊是同步模塊。以上面打的比方來說,盡管做到發送消息,跟處理模塊代碼分離。 但實際上執行過程沒有多大變化,也是要先注冊用戶完,然后完成一些列處理功能。最好這個php頁面才算處理完了。 需要時間還是那么些。 如果真的,能把這類跟功能無關接收消息,處理模塊異步到后端。 那么估計再沒有人抱怨wordpress打開一個要4,5秒了。


  • 后記:

就說這么些了,估計很多同人告訴我說。居然它性能不好,又慢。 你干什么還要用它呢? 這個就看你主要關注的是什么了,如果你需要快的開發模版,而且非常容易開發各種擴展。那么它是你最好選擇了。 況且,性能問題,一但靜態化后,幾乎解決了。

估計還有人說,你既然提到它性能這么些不足,那么你有什么好的調優方法沒有。 呵呵,這里歡迎大家交流意見,我也有一些想法,就先不詳說,還不成熟。歡迎交流!!!祝朋友們,周末愉快!


作者:chengmo  QQ:8292669
原文網址:http://blog.chacuo.net/67.html
訂閱保持關注:http://blog.chacuo.net/feed
本文版權歸作者所有,歡迎轉載,請務必添加原文鏈接。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com