沉于思考,默默学习!

你不能预知明天,但你可以利用今天。你不能样样顺利,但你可以事事尽力!

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  63 随笔 :: 0 文章 :: 712 评论 :: 0 引用

我还是觉得自己开辟搭建一个独立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
本文版权归作者所有,欢迎转载,请务必添加原文链接。

posted on 2013-05-27 11:27 程默 阅读(...) 评论(...) 编辑 收藏