play!framework，新一代ROR风格的full-stack framework_leonliucn的空间_百度空间
play!framework，新一代ROR风格的full-stack framework2010-06-20 17:45
文/刘欧
貌似正常的开发流程，总要面对项目原型构建的问题，重新发明轮子，或者把以前的家伙式儿再搬出来reuse一下？此时此景，都不是最佳选择。
90%的web业务开源系统都是php版本的，特别是新兴产品的开源实现，java的身影几乎销声匿迹了。可惜要java出身的人去阅读php风格的代码简直是一种受虐。这其实说明一个道理，java优美的架构还是很有价值的。但优美+务实的平衡才是最佳选择。
这不，基于java的类RoR风格的full-stack framework的话题又回到我的视线内了，
几年前是appfuse，基于此搞过几个小项目，但发现熟悉appfuse本身就已经稍重了。而appfuse看起来还真只是个toy，demo show +study 为主。
后来国内出现了springside，应该是借鉴了appfuse的思想，更简单，更符合国情一些了。基于springside开发中小项目也没问题，但国内的开源产品很少能在真正意义上通过多人协作持续变得越来越健壮，版本发布计划总是落单，向下兼容，核心代码等品质还不稳定。
再到今天的play!framework，几个同事也对play!framework很看好，貌似是目前java阵营里最ROR，同时java开发人员又最易上手的框架了。
不得不承认，web开发已经完全是php等脚本语言占优了，就算你开发新一代的企业级产品，你也会发现互联网化+轻量化也是个潮流。就算是IBM team collaboration software - Lotus Quickr ，虽然server端是开发了10多年的老系统。但quickr要做的也是在应用层上基于server做业务扩展。这样，再复杂的系统，在前端应用层上来看其实也可以轻装上阵了。
很多java开发人员对ROR风格不屑一顾甚至根本不关注，不了解，也许是被sun+ibm下毒太深了吧？其实想想，spring的基于接口 bean管理的xml在很多时候也是写一次，到项目下线也未曾修改过。
java本身也太过强调仅仅java语法层面上的通用，抽象，配置，甚至太OO了，在java诞生的时代，这种做法是很先进的，而当今web应用开发算是一个特定领域，这种不与时俱进，不考虑web开发实际特点的做法有点杀鸡用牛刀之嫌，必然打不过转为web开发场景设计的新的动态脚本语言。 java毕竟不是专为web开发设计的语言，随着时间的推移，java的身躯越来越笨重，版本升级很慢，期待jdk7加强对动态语言的支持:JSR292。但这还不够，就像ruby on rails一样。还得有一个rails框架支撑。java官方的脚步实在是。。。只能用非官方的框架了。
在中国，企业级系统至少一大半是比互联网线上产品还小的系统。特别是中国互联网公司的玩得还是硬气功，之内的企业级系统开发很多还是停留在一个人，两三个人搞定一个系统的层次上。那这样看来，就算有人认为play!framework不一定适合巨复杂的业务系统，那怎么也很适合这样场景的系统开发了吧。
appfuse更新的越来越慢，是有原因的。因为play!framework这样的新一代类java ROR full-stack framework已经初长成。Grails，JRuby，也占据新一代java 类ROR full-stack framework的市场，但与之相比，play!framework的好处是兼容现有的java代码，语法，更加适合过渡期的需要，当然由于基于java这种强类型的静态类型安全检查语言，这也势必通过一些hack手法使play！变得很ROR。
周末网上找了些资料，在电脑上play了一下play！framework，的确比appfuse，springside都RoR，当然就更好用。
play!framework 是无状态的mvc框架，搭配memcached，伸缩性应该没啥问题（集群水平扩展应该很好做。）
play!framework 支持jrebel类似的j效果，修改java代码，无须重启，热部署，很方便。再也不用重复edit-》complie-》deploy-》running漫长之路了，
还有，java mvc框架最麻烦，最弱的就属view层的模板语言和js实现了，play!framework 采用的是Gsp （Groovy server page），及jquery框架。模板语法简练很多。
也不要被play这个词蒙蔽，play!framework 还是很DDD的。只有属性和get，set方法的贫血模型不见了，取而代之的是有行为的充血模型，很DDD吧。
play!framework 真的很full-stack，连httpserver都给你提供了，
play!framework 用Python取代Maven来完成创建，运行等与系统的交互。appfuse之所以学习成本比较高，其实都花在maven本身的配置，理解，使用上了。Python应该更适合于系统打交道，更轻便吧。
play!framework 本身支持插件机制。扩展应该也没问题。估计也一大堆可用的组件，这个很重要，http://www.playframework.org/modules：spring ，orm（应该也有Ibatis吧），lucene search，MongoDB，甚至Scala。都很不错。
想在Model层用一下nosql的话，Siena组件可以做介个（Siena orm+mongodb就可以了吧）
The siena module automatically enable Siena support for your application.
Read more at http://www.sienaproject.com/我想，支持可插拔组件的框架是衡量一个好框架最重要的指标，一下子事无巨细都塞给你，你肯定消化不良，由繁入减可太难了。好多开源实现都犯同样的问题。搞得你在相当长的一段时间内很头大，饱尝贪多嚼不烂之苦。play!framework 的默认配置可真清爽，连spring bean管理都不是默认配置，根据业务需求不断做加法，正是我想要的。哈哈。
缺点肯定也有：
比如资料有限，play!framework 刚1.0时间也不太长，bug也再所难免，引入的新技术和新思维也需要一定的学习成本去适应领会，play!framework 利用自己框架的classloader背地里搞了许多手段，虽然用户一般情况下不必了解，但或许会给某些场景下的测试带来一定的麻烦。
有人声称play!framework不适合多人协作开发，晕，门户网站千万级用户量的系统核心开发人员也不会超过5-8人。更何况，在多人开发的情况下也是尽量一人负责一块儿的，相反，现在好多开源框架恰恰过多考虑了不符合中国实际的多人协同开发场景，搞得框架分离得过于松散，过于流水线，搞得一两个人开发项目时，反倒觉得麻烦得要死。所以不适合多人协作开发好像也算不上什么缺点。况且Using Play modules可以拆解复杂系统的开发。
毕竟play!framework本质上可能还是一个过渡期的产物。设想一下，如果jdk7的JSR292很成功的话，各种基于jvm的动态脚本语言会层次不穷，保不齐，就会出现一个一统江湖的jvm动态脚本语言及相应的框架，当然，空窗期或许会很长，也不用死抱着struts等老一代mvc慢慢啃守株待兔吧。
ROR COC就是要改变java程序员妄图对一切应用都机械地力求基于接口编程，通用，显式配置才放心的习惯。大部分web应用开发只要做到webservice restful api层面上的面向接口编程，和通用性基本就足够了。不要忘了restful api本身已经是抽象得巨好的架构了。这样，web开发人员才可能提升开发效率，把时间和精力放到业务逻辑本身，这样才有敏捷开发的可能。想想，如果你的开发要点和时间都消耗在未雨绸缪，坐在椅子上凭空想象n年后的需求变更，而作所谓的基于接口编程，再加上缓慢的编译，部署，运行，怎么可能适应敏捷开发的要求呢？反而会导致一个项目虎头蛇尾，前期优雅得要命，后期丑陋得要命，都往action甚至jsp里堆代码了，何苦呢？反不如，一开始就低下你高贵的头颅，心平气和务实地去ROR了。
总之，简单说，如果play!framework真的兼容了java与php，ruby等动态语言的优势，那就是目前java人员web开发最佳的选择之一。如果说ejb是老年太极拳的话，play!framework就是java世界里的截拳道，一个拥抱得起变化的，适合敏捷开发要求的技术框架。
先用起来再说啦。