我对"play" 框架的看法

这段时间,发现 "play" 这个名字多次出现,看介绍说是"纯java ,动态编译,运行速度快,开发效率高 ..."(详情参见"Play! 一个Rails-like的Java框架 ","Play with Play! - 框架概要 ")终于按奈不住挑逗,于是抽了一个晚上到它网站上逛了一圈.终于识破了它那掩藏在虚假漂亮外衣下的本来面目,play 漂亮的外衣就不说了,已经有很多溢美之词.说说它的问题.

controller 的问题

controller 被设计成为类中的静态方法.这使得controller丧失了oo语言平台的种种优点,换句话说--直接自宫.过度使用静态方法有什么问题?这方面有很多资料.例如("The Essence of OOP using Java: Static Members ","Static Methods are Death to Testability ").

 

在"play" 的宣传册 "Five cool things you can do with Play! " 中有一条:

"Bind an HTTP parameter to a Java method parameter"

这句是废话,在控制器中访问经过转换的http参数是一项最基本的要求,例如struts2 直接转换成为controller 的 property
play 的控制器被设计为静态方法,所以http参数就只能以方法参数传入,没有这一点,这个框架根本不能用,而不是什么"cool things"

 

 

组件模型的问题

组织代码只有两种选择, controller, model.

controller:
如果想用controller? 考虑下如何用类的静态方法组织代码---这不是变成过程语言了吗?你真的很想用过程语言来组织你的业务逻辑?

 

model: 
play 的 model很明显是充血模型,关于贫血模型和充血模型哪一种更好,已经浪费了很多口水,这里就不在赘述.这里的问题是play 根本不提供第三种组织代码的手段(service),那么一旦出现某项业务逻辑操作多个领域对象的情况,这些代码应该放在哪里?

 

另外有一项限制更绝:
"Does not keep any object into the Java heap for multiple requests"
这个要求把play的应用从第三方的类库中隔离开来.意味着你使用其它类库之前要考虑下是不是满足这条要求(估计多数情况下不会满足)再好好想想,你真的能保证永远不再用第三方类库了吗?

 

事务管理的问题

事务,对企业应用的重要性就不必多说了.spring 能够如此popular的一个重要原因也正是它把强悍的事务管理以简单的pojo的方式提供给应用开发者.其它web 框架无有不提供和spring 集成的手段, play 为什么漠视spring? 还是由于 "Does not keep any object into the Java heap for multiple requests"

 

非j2ee stack

难以在主流市场上获得认可。

 

综上所述: "play" 在设计上有重大缺陷,现阶段只是个玩具(正如项目的名称一样)