>백엔드 개발 >PHP 튜토리얼 >关于PHP事件驱动问题之我见_PHP

关于PHP事件驱动问题之我见_PHP

WBOY
WBOY원래의
2016-06-01 12:31:451164검색
  看到有人在讨论PHP的事件驱动问题,本应回复一帖。但认为回复不足以引起大家的重视,故专开一帖详述本人对这个问题的理解,并对一佳作进行解释与分析。

  事件驱动这个概念是广义的。可以在客户端,也可以在服务器端。

  在WEB应用上,在客户端的事件是基于JS或是插件或是JAVAAPPLET之类的东西,基本上如果是插件或是JAVAAPPLET的话,就不属于HTML的范畴了,而真正必须用到JS的场合其实并不多,最多就是FORM的提交或是链接点击之类的基本操作,因此谈论事件无太大意义。

  事件驱动真正的意义并不在于可视化编程,而在于它的概念,就象OO一样。事件驱动其实是OO的一个延伸,它的最初原型是消息机制。但是事件驱动把消息封装成了一个可调用的函数,有些类似于API中的回调函数,你自己可以定义这些函数执行的内容。而可视化编程则把这些函数独立出来,定义好参数(多数是现成的对象),让你自己写代码并运用这些参数(其实是用这些对象)做一些事情。

  所以,PHP有事件驱动是完全可能的,主要在于框架的设计。而要做成VB之类所谓的可视化事件驱动,则必须要有配套的集成开发环境,包括页面设计,事件编码,编译转码之类的一系列功能才行。其实象点NET这样的事件驱动,只不过是把一些常用的WEB元素或控件,如按钮、文本框之类的东西封装了一下,让你有个可视化的界面可以设计一下,当它编译之后,仍然是之类的文本,只是把你的事件代码转为了JS或是服务器端代码而已。而PHP主要是由于IDE不够丰富,而且也没有预编译机制,所以最后提交的代码还是最终的PHP代码,而不是点NET的资源代码与事件代码的混合体(一般是符合XML规范的ASP文档,包含了非标准的HTML代码)。故此PHP还无法达到大家心目中狭义的所谓事件驱动编程,但其实是完全可以没有问题的。

  如果大家感兴趣,不妨到www.php.net官方主页去看一下一位中国哥们(Qiang Xue)写的一套基于事件驱动的PHP框架PRADO,这个还是获得高票当选的最佳,强烈推荐!请参考 http://www.zend.com/php5/contest ,你看了他的源代码后就会理解PHP的事件驱动是怎么回事。但我认为,在这上面,由于PHP无预编译机制,而且过度依赖OO(虽然是用PHP5写的代码),造成这个框架有些庞大,且使用比较复杂,可扩展性也不是很好。不过,其中的理念非常之好,有些想法还解决了困惑我多日的问题。我下面简单介绍一下这个框架。

  该框架用ZDE及PHP5写成,有详细文档,结构十分清晰,注释极为充分,代码非常易于读懂,说明作者写码水平非常之高。作者明确说明,这套框架参考了ASP点NET及Borland Delphi的概念。

  这个框架在验证性上非常之强(并不是指里面有什么验证登录之类的模块),十分健壮,几乎不可能有什么直接的漏洞可以从外面攻入,它是引入了规范文件这个概念做限制,很有效地解决了大量验证时的效率瓶颈,这种验证方法只有一个问题就是规范文件本身的制作比较费力(当然用工具的话是另一回事了),然而一旦做好(规范文件本身有格式与规范的),验证就自然而然地由框架去做了,而无需每次人为调用。它的事件也可以定义在规范文件之内(我却认为这就没有必要了),其实它的规范文件就有点类似于DELPHI或是VB中的FORM定义文件,只不过是用XML写的纯文本,而非可视化。而对于事件驱动,框架内置了一套与点NET类似的基本事件流,你可以在不同阶段定制这些事件,其实说白了,就是重新定义这几个OnXXX函数,用给定形式的参数,你也可以自己加入自己的事件,比如你在定义自己的组件时,在规范文件中定义好该组件可能有的事件函数及参数,以后你在使用该组件时可以直接定义这些被允许的函数——不过我认为这种方式过于复杂,且要大量读入并分析XML文件,虽然十分地严谨,很安全,但有些过分了,也没有充分利用到PHP本身的灵活性,我的思路是用类似于DELPHI的函数句柄赋值的办法或是用C的回调函数的特性,即可在写代码时在任何时间任何地点定义事件,而仍然能明确事件发出者及类型并有足够地安全性保证,且无需机械地强制各个组件只能有哪些事件,代码修改及扩展都十分方便。当然,在做大项目的时候,严格的定义是必要的,不过,即使如此,该框架处理事件的方法还是有些古板。

  它的模板我认为是一个比较好的想法,它的模板有些类似于点NET的ASP文件在编译前的文件(我对ASP点NET并不熟,但明白一些原理),但起作用的方式则类似于DELPHI的FORM文件,是一个很好的概念,唯的一缺点是用DW之类所见即所得的通用编辑器则感觉不是很顺手,因为一个模板中可以同时把几个互斥的组件放在一起,而只在运行过程中决定显示哪些。

  就我本人看该框架的代码,还是发现它有一些非常弱的项。其中最主要的一个就是路径的问题,可扩展性很低,应该比较适用于专用主机,对一些受限主机(目录限制或是权限限制)就无能为力了,也无相应的提醒措施(也无相关接口)。它对某些资源或文件的路径,用了一种繁琐的叫assetService的机制,目的就是确定文件的路径,作者自己也说,如果用了这个服务,系统消耗会明显增加,其实这个是借鉴了FLASH中asset library的概念,它这样虽然可以任意指定路径,但每次都必须重新校验,有些得不偿失。我的作法则是固定好几个主要路径,而其的子目录都可随意,就综合平衡了两者的矛盾。由于对路径问题缺乏考虑,导致该框架对语言设置、个性化模板等无能为力,如要翻译一个项目,手续之繁,工作量之大是可想而知的,而且极易出错。这是该框架中最严重的一个问题。

  从总体上来说,该框架的理念上,设计上,代码上绝对都属一流。当然不足总是有的,不过完全不妨碍我们研究及学习它。它的代码我并未全看,只主要看了几个核心程序及一些说明,但已能足够看清楚其结构与思想,对作者深表佩服,但对其中的不足也深表遗憾。不管怎么样,它都绝对是研究PHP事件驱动代码的好作品。因此强烈推荐!
성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.