关于框架(FrameWork),尤其是PHP开发框架,现在真是漫天飞舞,让人眼花缭乱.想当初我设计第一个所谓的框架时,PHP可用的框架基本上是空白,所以很多东西是参照Java的特点来作的,那时年轻,也有些轻狂,以为框架就这么容易做出来了.设计框架会有一些偏差:首先一个问题,框架=类库的聚合. 这种情况一般是设计者有些代码开发的经验,但是缺乏更广的知识沉淀.不经历风雨怎见彩虹,如果没有涉足多个领域的痛苦折磨,仅仅在某个,某些项目甚至某个开发语言上有些涉足,就想,框架不过如此而已.于是乎,框架就在复制粘贴的过程中产生了.其实,一个框架代表的是一个思想,一种哲学,类库只是这种哲学的附属品罢了.第二个问题是设计过度,偏离了实用. 这种问题产生于一些比较追求完美主义者甚至是大师,为了完美,设计而设计. 比如spring在最初版本中,其MVC就有些不太实用的地方,这点对比webwork/xwork就能发现,不过后来随着使用者的增多和流行,这些问题也很快被消除.看来,实践是检验真理的唯一标准.上面2个问题在我身上都印证过. 尤其是第二个问题更为明显,自身功力不足,却强行希望看上去很美,导致了现实和理想之间的差距.所以,在doggy之前,我虽然也自己实验过一些原型,不过很快就被扔掉了.现在,在作doggy的实现时,我更多的是考虑,哪些功能是确实需要的,哪些是体现我的理念的,后者是首要实现的.比如,doggy的一个最重要的思想是:支持TDD开发的模式,测试先行,测试驱动. 因此,对于测试的支持是首要必备的,此外,对于持续构建,项目部署分发,也是实际中很现实的问题,这些也需要重点考虑.至于扩展性则放在第三位,这里所谓的扩展,并未局限于框架代码本身,而是和整个系统的部署,所谓网站的系统架构上综合考虑的.例如,在存储层的扩展,是需要考虑能否支持分布式存储,本机开发是一回事,但是能否部署到如mogilefs,hardoop.如何支持fastcgi的部署,如何最大化利用lighttpd,nginx,varnish.缓存上,3级缓存中,各级缓存在实际中如何去实现,这些需要doggy去支持,否则就无法扩展系统.比如,在cms中,多数文章是可以使用静态文件生成,并分发到cdn等负载钧衡网络中,那么如何过期,如何刷新,则需要考虑cdn网络如何去构建,是用nginx?nfs共享,磁盘阵列gfs?还是用squid,varnish的反向代理?这些都是doggy需要去考虑的.当构建web2.0的应用时,需要考虑的是另一种情况,此时,单纯采用静态化已经解决不了问题,那么需要使用局部缓存,解决并发的数据读写,如何保证数据的实时更新和同步....再比如,确保应用服务和静态服务的分离,项目的开发和部署的隔离...因此,对我而言,应用框架需要解决不仅仅是代码层的优化,更要解决的是一些实际的应用.doggy框架,我姑且仍认为它是一个应用框架,在应用层面则是提供一个解决这些问题的方案,这是我所关注的.而其他的一些东西,我认为并不重要,比如,url/action的route方式,doggy只支持一种,足够.为什么?因为我可以通过其他的方式去弥补,比如可以在Nginx的rewrite实现,可以使用lighttpd的lua实现,这些方案的效率远远高于PHP,那么何必去实现这些吃力不讨好的东西呢.因此,doggy不是通用的,它需要unix环境,不支持windows的部署,开发环境最佳是linux/osx,window则需要使用cygwin,必须使用一些定制的pecl extension,PHP需要作一些特定的优化,webserver需要最适合的等等.也许,我是在自娱自乐,但确实好用.
