ThinkPHP规范化见解

一、 配置信息、初始化的句柄(例如数据库连接句柄)等使用 全局变量 、 常量 还是 TP提供的 C等函数处理方法

1. 历史原因用 全局变量 和 常量

早期的很多php程序都是用全局变量或者常量储存配置信息，因为它们具有全局可见性，不过TP有自己的办法替代它们原因如下：

1.1 全局变量已被弃用

全局变量的值因为可以在整个程序的任何地方改变，或者会与程序段中的变量命名产生冲突，严重不符合开放、封闭原则，其安全性无法得到保障，所以现在的系统很少再使用全局变量来当配置信息和初始化句柄。

1.2 常量不够灵活，无法适应改变
常量可以全局使用，并且不会在程序中被改变其值，这是它比全局变量有优势的地方。
但常量没有灵活性：
首先体现在它的值只能是标量(句柄会产生意想不到的问题)，
其次，如果你想改变一个系统的配置，无法由管理人员在后台做设置，只能通过程序来改变。

举个例子：原来网页上某块区域显示的分类ID是5，现在要把它改成3，如果用的是常量配置，那程序员必须去改程序，系统管理人员将无能为力。

2. C等函数优势

2.1 全局可用性

函数在被加载入内存后，就是全局可调用的，意味着在程序的任何地方你都可以使用已经加载入内存的所有函数。

2.2 可以数据驱动，灵活改变

C函数保存的配置信息是可以被改变的，而且可以存储任何类型值，这是它比全局变量有优势的地方。

我们可以通过系统管理程序，让管理员在后台改变配置值，程序里可以读出管理员设置的新值，覆盖旧的值，用数据驱动的方式达到不需要程序员干预的目的，实现 维护程序 到 管理系统 的改变。

2.3 在行为扩展里初始化
当然大家也看到了C函数也在一定程度上不符合开放、封闭原则，不过我认为可以用以下几点解决这些问题：
2.3.1 首先C函数不象全局变量那样，在你程序段中命名变量时会产生命名冲突。
2.3.2 只在程序初始化时改变C函数的值，不在运行期变动。因为TP提供了行为扩展，那我们就可以在TP的初始化行为时从数据库(或者其它存储了管理员配置的地方)中读取新的配置，更新到C函数里；如果真的是因为TP本身架构的制约(TP里某些类的方法抽取不到位，没有单独把读配置信息的方法抽取出来，造成了初始化这些类实例时，要动态改变C函数的值才能使用)，非要在程序运行时动态改变C的配置信息，那最好也是先保存现场，等初始化完成后再恢复。
2.3.3 除了上述的情况，我还真想不到为什么非要把一些数据记录在C函数里，因为TP本身也提供了其它的函数来存储运行时的数据，所以根本没必须这么做。

二、 模板文件的URL规范

1. 很多老的程序员，对资源文件引用的方式存在弊端
在WEB程序开发历史上，早期的资源文件引用都是简单的使用从根开始的路径(比如这样引用图片<img src="/Public/img/1.jpg" />)，这样做没有考虑到这个系统可能会被放到一个子目录下。

可以说我是个后WEB时代的程序员，在我开始写WEB程序时，很多事情已经没有那么简单了，不能再以简单的方式来解决问题，这里我指的不仅仅是HTML上对资源文件引用的路径处理，还有其它地方，考虑的事情都比几年前多很多。

2. TP提供的U函数等处理方法

TP里提供了U函数来专门解决引用路径问题，你要假定你的程序不一定会被放到网站的哪级目录，你唯一能确定的是资源文件与程序入口文件的相对路径，用U函数将产生相对于你入口文件的正确路径。

3. 正规的URL规范对环境因素的依赖性。

让我用现实的例子来说明一下问题。

每个程序员都有不同的项目，WEB程序员更有其特殊的一点：因为网站服务软件的特点，几乎所有程序员都会在同一个目录下存放自己所有的项目，这样只要把服务软件的配置指向这个目录，那所有程序都能找得到。

对！我说的是找得到，不是可以正常运转起来，这是为什么呢？很多程序没正常运转，最大的原因就是HTML上引用的路径不对，找不到css、js、图片，你的页面将是一团跟乱码差不多的东西。

于是你就开始给每个项目绑定一个域名，问题得到解决。那我就稍稍提以下几个问题：
(1)如果你的项目很多，你对配置的维护量是多少？
(2)如果你的服务配置因为各种原因丢失了，你重新绑定的工作量是多少？
(3)你要让相关测试人员来访问，他们需要是否也要在他们的电脑上做设置？

(4)你这个程序是否直接放到生产服上就可以使用？万一有些突发事件需要移动到其它地方呢？

如果你回答不了，那我们就做个对比吧：
(1)我刚来公司时，要对旧有的系统进行扩展，老的程序员丢过来的每个程序都要绑定一个域名。
(2)我把原来的APACHE改成NGINX，为了重新绑定这些程序的域名，没少花时间。
(3)这些系统要让相关人员能正确访问到，必须告诉他们正确的域名绑定方式，然后一个个去改hosts文件，有经验的人员还好说，没经验的人员你就手动过去绑定吧。

(4)这些程序如果服务器出问题了，零时又申请不到域名(ND公司的域名可不是你想有想有就能有的)，你就只能扔到其它系统的子目录下，这里将是你抓狂的开始，因为几乎所有模板文件你都要改变路径，从 /Public/ 改到 /subdir/Public/ 可不是字面上这么简单的事，至少我一进公司时帮一个系统改这些路径花了我近三天时间(最终还没用上，杯具啊)。

我写的WEB模板，所有的路径都是老老实实的用U函数(或者系统提供的一些其它正规方式)来生成，我的程序不需要在服务软件上做配置，扔到主目录下就可以直接开始跑；我的服务软件配置丢失了也不用担心，就是指向主目录就好了；我的程序如果让相关人员来测试，我告诉他我电脑的IP和子目录，马上就能访问；我的程序可以随便扔到其它系统的不管哪级子目录下，比如我的 z91 的后台就扔在酷玩汇一个子目录下，一上传就开始正常跑了。

使用一个框架，本身就是要使用它的规范，那当然是要按它的规范来要求自己的程序编写方式。开发时为正规化所花的时间精力，将体现在后期维护的便利性上。只有基石是稳固的，才能保证上层建筑能经得住风雨。

转载请注明出处

福州 郑洪耕 QQ:823339113   2013.06.12