见到有些人在探讨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量化策略编码的好著作。因而极力推荐!
