长篇大论
1. container
现在提到container, 最容易让人想到的估计是IoC container了. 大红大紫的IoC继续红火着, 占据着大量的市场份额. 而我对这个container的依赖也日益加重. Autowire也大肆加重了我的懒惰. 懒没有坏处, 只是总觉得还不够懒.
那天在club.phpe.net上有人在问, 能否有一种方式由页面(模板)主动得去请求. 就像一种页面级别的autowire了. 但必然带来大量约束. 如Webpart和Portalet.
2. framework
framework并不是说做就能做出来的. 特别的, 请不要把带有自己实验性质的framework随意公开, 更多的应该在有限的人群中进行着讨论, 测试, 改进. 当在有限的人群中得到认可再公开不迟. 至少得要告诉别人, 这个还不要相信, 因为指不定自己哪天都会丢弃这个东西. 当然在不断摸索中不断进步是必然的.
3. rails
rails系列其实并不能算是framework, 就像appfuse一样, 更多的像是个tool, 一个raid develop的工具. 就rail系列的特点而言就是核心是一个simple的orm (active record)和一个simple的mvc. 而且有着大量的限制. 去年迷恋自己创造php的orm, mvc及自己的php framework的时候曾写出大量的相似代码. 然后就是一个接一个的否定. 约束太多.
4. our php
那时候公司的php的开发框架是由Avenger一手搭建起来的, 对于这个历史悠久的框架我和av都有着一向以来改变或者流行一点说就是重构它的想法. 之前的结构大概如下:
一个admin.php加上一个基类mod_main, 即充当frontcontroller, 又充当Reource Loader, 还充当Permission Filter, 并还要负责输出. Resource基本分为Global的和Module的, 主要包括语言和DB. 一般开发的时候就是写一个mod_main的子类, 调用一些封装好的方法, 然后进行一个模块一个模块的开发. 其实挺简单的, 开发好模块, 然后配置进系统, 然后设置权限, 便开始工作了. 以这种方式下, 已经开发了大量的模块了. 于是开始很头痛, 最大的一个PHP文件已然101K, 2400多行. 每每看着就觉得头大如毛…… 另外一点就是耦合太高, 实在难测试, 别说unittest了.
于是改造工作终于开始. 把Action抽象出来, 搞个ActionRunner用于执行, 同时根据不同的ActionResult而调用各自的ResultTypeProcessor进行处理, 并处理过的返回结果. admin.php和mod_main职责不变, 继续充当原先的角色. NewModule按照原来的规则继承mod_main, 并负责调用一个简陋的Contanier(只能显示的代码注入)来创建并autowire DAO及Action, 当然在PHP中autowire肯定是只能byName的. Container抽象出接口, 并由Context统一调用, 以便随时替换掉这个简陋的container的具体实现. Context根据不同的环境(Console Or Web)创建Request的实例. 另外写了一个Action的测试基类, 负责初始化Action所要load的resource. 至此, 改造工作基本完成. PHP未必需要xml, 因为对于PHP程序员来说他们对php代码肯定更加熟悉. 而且php代码解释性的特点, 所改即所得. 而且偷懒, 所以还是选择显式的代码形式的注入. 支持简单的init和destory.要在PHP中彻底引入Application和Lifecycle概念并不容易.
4. php
其实php一直以来开发模式不能转变的原因之一就在于没有一个application的概念, 而所有的生命周期就在于一个一个Page, 而Page的生命周期你完全不能控制… 于是传统的PHP开发总是一个Page一个Page. 后来慢慢的一个模式在PHP开发中大行其道, 就是FrontController模式. 我想引入FrontController模式的初衷应该就是为了Application的概念, 为了能控制PHP执行的顺序, 甚至Lifecycle.
5. mvc
一般的MVC分为请求驱动和事件驱动. 其实要做到一个好的MVC不算是难事, 但要做到一个大家都喜欢的MVC就难了, 因为表面的东西, 大家都特喜欢鸡蛋里挑骨头. 就像我老是顽固地认为事件驱动容易增加代码的复杂度, 不适合web. :p
IoCphpmvc
不错呀，最近经常更新，值得表扬
不知道有没有时间给flea1提提意见呢?
项目主页
http://www.dualface.com/projects/flea1
2. framework
framework并不是说做就能做出来的. 特别的, 请不要把带有自己实验性质的framework随意公开, 更多的应该在有限的人群中进行着讨论, 测试, 改进. 当在有限的人群中得到认可再公开不迟. 至少得要告诉别人, 这个还不要相信, 因为指不定自己哪天都会丢弃这个东西. 当然在不断摸索中不断进步是必然的.
我想这就是他的意见了，哈哈。