Chinaunix

标题: php程序框架及OO的一点看法 [打印本页]

作者: Aryang 时间: 2007-12-30 16:19
标题: php程序框架及OO的一点看法
从目前用到的最多的apache+php的搭配来讲，php和实质还是cgi。cgi就是程序或脚本设置环境变量&输入、加载、执行、输出、销毁。在这方面是与java web是截然不同的。

java web开发的核心是servlet和容器（jsp也被编译成servlet来运行），总的来说就是web程序员在实现servlet基类的子类，容器收到http请求后实例化servlet对象，负责管理servlet的创建运行销毁的整个生命过程。java的整个web是运行在一个进程空间内的（或jvm虚拟机），这样可以有很多方法提高系统运行效率，比如对象池，数据库连接池等。java里oo的应用是必然的。

php从形式上学习java那一套我认为是不可取的。一个http请求过来，php所有的对象都要从头读取加载创建，脚本结束后所有对象烟消云散。php解释执行的方式更不能跟JVM的JIT比较。

php的oo也不是一点没有用处。在php里，我认为oo主要用在功能性的包装上，比如adodb数据库对象，用户对象，复杂功能的form对象、html table对象等。

对应php整体框架来说，我个人认为更适合采用传统的过程方式，不要搞什么Application，Page对象。在使用顺序过程的方式的时候，要考虑几个重点问题。

1.一定要用单入口的方式，既面向用户只有一个index.php之类的单脚本。唯一入口从结构上可以集中处理url改写，任务分发，权限控制，防止恶意注入等（当然在不同页面里共同include一个集中处理的脚本也行，但那样失去了强制约束）。

2.OO里模块功能类和action方法转换为module目录和action文件。（这一点是我个人的习惯，不代表最佳方案）。用模块功能类（每一个模块功能写成一个类，分成若干action方法处理具体事务）的最大问题是：模块的规模不好控制。假设是一个论坛程序，我们会面临一系列抉择。显示子论坛，显示子论坛文章列表，显示内容，添加文章等功能，都需要划分若干类。从不同的视角，会产生不同的类的设计。有时候发现，虽然从逻辑上清晰合理了，但有的类几百行代码，有的类方法多有好几千行代码。单一代码多了可维护性降低，而且类中一个方法的语法错误，将导致整个类甚至程序的调用失败。
采用module目录和action文件的方式将解决（再说明：这不是电视里阿波罗活性肽的广告，只是适应我个人情况的方案）功能代码规模的问题。基本的url格式为：

index.php?module=mm1&action=show&xxx

入口合适权限后include module目录下的 module同名.php文件（相对于是类的构造函数，可以处理整个module的公共事务，网页的头部或网页的基本结构显示）,然后 include module目录下的 {$action}.php。action文件可以是段php代码，也可以是嵌套php代码的html文件，这点很灵活。或是一段模板初始化代码，结尾处include 一个嵌套php代码的html模板（混合式的php本身就是最好的模板，为什么非一定要用smarty呢？）

3.权限。在基于第二点的情况下，权限就很好解决了。权限可以分为两种类型，一种是对应module和action的权限，一种是虚权限。对应module和action的权限完全是自动化的处理，在脚本或数据库里配置好后，由index.php入口自动判断处理(我个人目前实现了权限不够菜单和功能链接自动隐藏不显示）。对于action基本的粒度还不能满足的，使用虚的权限，直接通过if语句判断。

4.性能优化。php本身的运行方式和大量的include必然导致性能下降。针对php解释执行慢可以采用各种代码编译和加速的方式（eAccelerator,XCache等）。为了提供用户体验满意度，还可以采用ajax等技术。比如在index.php里直接输出含有ajax代码的静态主页面等。还可以借鉴smarty的“编译”方式，将页面里的include直接用include目标文件内容代替。当然这一变化是在index.php入口内部的处理，对用户透明不可见，不影响用户接口。

5.数据库对象

6.用户对象

未完待续。。。

任何应用框架必然带来的是某方面开发效率的提高和某方面灵活性的降低，挨砖是必然的，所以我也不敢发表什么框架。这里只是提出一些个人的心得和看法，偏颇也是必然的，愿与各位多交流促进。

作者: angeljyt 时间: 2007-12-30 17:24
java里oo的应用是必然的
这个是100%肯定的啦, java本身就是基于面向对象的，不oo难不成还要返古。

php的oo是半路出家的, 到处取经

作者: young1012 时间: 2007-12-30 18:36
可能OO是以后的趋势!

作者: achieverain 时间: 2007-12-30 18:49
关于smarty的问题.我就被逼由自写模板类转为smarty.毕竟smarty是php中型到大型开发模板事实上的标准.

另: php+html 制作模板会导致致命的安全问题.况且你可以逼迫美工学习smarty,但是你无法逼迫美工学php.

作者: alexru 时间: 2007-12-30 18:51

原帖由 young1012 于 2007-12-30 18:36 发表
可能OO是以后的趋势!

趋势是肯定的，但还得看要解决的问题

作者: super_fire 时间: 2007-12-30 20:12
OO只是一种思想，不用一个class也照样可以实现OO思想，只是没有用class方便，drupal就是这样实现的。
即使是号称纯OO的java，上来就是class、class、class，没class不干活儿的主儿，也完成可以以OP思想实现代码。

OO与OP，都是程序员思想上的，或者说设计上的不同。OO适合人类的思维方式，OP更贴近计算机的处理方式。

作者: phpnewbie 时间: 2008-01-01 15:13
不管黑猫白猫，能够抓到老鼠就是好猫。

作者: ashchen 时间: 2008-01-01 15:43
目前以及将来很长一段时间，php都是一次性筷子，一次性筷子有必要做的很精美耐用吗？

作者: bs 时间: 2008-01-02 09:08
原本也是想用OO做PHP，但后来发现，不如用 java和PHP相结合的方式，各取所长，每种语言总有他的优缺点，只是我们使用者要灵活应用

作者: sunnyfun 时间: 2008-01-04 13:36
OO的好处多多，虽然说效率是个问题，但是为将来能够省事打下了基础。有时候，特别是一些需要维持状态的情况，使用类会方便很多。
不需要从头到尾满眼都是类，但是如果意识到某个功能将来可能会重用的话，就应该有意识的，毫不犹豫的写成类。

作者: weicky 时间: 2008-01-07 22:52
你不喜欢用面对对象的方式你可以不用，但是如果我们这些靠这个吃饭的人是不能不用的，面向过程，连个pear也用不上，什么模板了，xajax了，开发框架了，就连个分页的pager都用自己写，等这些准备工作都做好了，工作也被辞了几次了。还有不得不说的是，开发框架也许会在性能上带来一些影响，但那是值得的，至少我们可以针对逻辑功能设计模块，PHP的代码也变得更整洁，大大缩短了项目开发周期，为什么不用呢？说到性能，html最高效，那我们就不用动态了吗？

作者: Aryang 时间: 2008-01-07 23:29
呵呵，楼上的，你没仔细看，我没说不能用OO，没有几个偏执狂非跟pear，分页pager（这个分页类大部分phper都能自己写吧）什么的过意不去

我说法式面包不合口味，你站出来说面粉比大米有营养是不是有点不对头啊

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)