【转】play总结性介绍

2019独角兽企业重金招聘Python工程师标准>>>

        颠覆臃肿的JavaEE开发框架（bloated Enterprise Java stacks）的Play框架1.0发布，它在很多方面有其革命性的独创，也有助于我们了解现在JavaEE框架的不足。

        Play框架吸收PHP RUBY动态语言的特点，采取即时源码编写，即时激活，框架本身融合了编译器和服务器。取代了compile-package-deploy 过程，提高产品的开发效率。Play框架甚至提供在线编辑器，在线修改BUG后即时投入应用。

主要架构特点：

        1、一个非常简单的开发周期。此框架自动编译和重新装载源文件的任何改变。

        2、简单的无状态MVC架构：智能捆绑HTTP参数到Java方法参数。
             Play框架认为一边是数据库保存状态，一边是浏览器也可以保存状态，那么还要中间件MVC保存Session状态干什么呢？HttpSession有很多问题，虽然可以处理针对某个用户的状态，但是万一用户中途离开怎么办，HttpSession对资源消耗，以及在可伸缩性方面是有问题的。Play框架秉承share nothing架构思想，不再象黑客那样破解原本自然正常Http模型，然后强行植入状态，无状态架构可以并行同时输出多个页面，提高Web性能。

        3、内置基于Apache Mina的快速HTTP服务器(从Play 1.1开始改用netty)。

        4、一个基于Groovy的强大的模板引擎，具有多层继承，定制用户标签的能力，Play框架认为JSP & Expression Language模板机制很好，但是需要太多配置，吸收其模板设计，剔除配置。等。

        5、优秀的错误报告功能：当发生异常，此框架会直接显示出错代码，甚至是模板代码。
        6 、RESTFul

            众所周知的Servlet API 和Struts其实是扭曲的，使用奇怪的API将Http协议隐藏起来，Play框架认为一个Web应用框架应该给完整地、直接地对Http调用和使用，这其实就是RESTFul精神。这样 URI是play framework的主要概念。对一个Java对象的调用，不是写Java语句，而是使用URI就可以，例如：

GET /clients/{id} 实际是调用Clients对象的show方法。

        7、集成JPA 持久层

            Play框架采取JPA作为持久化，并且使其更方便使用。
           
        8、整合了mencache和ehcache缓存
        9、融入了OpenID 这样单点登录SSO技术。
        10、提出组件重用，可以重用各种组件，包括CSS Javascript

         总体来说，Play框架是一个与Struts2 JSF Tapestry竞争的框架，但是又整合了持久层和服务器。

-----------------------------------------------------------------------------------------------------------------------------

运行方式与服务器兼容性：

 

        Play 应用可使用这么几种方式运行：标准Servlet容器、独立服务器、Google App Engine、Stax 云计算平台，等等。 最近云计算平台heroku（http://www.heroku.com/）也支持Play

下面的应用服务器都可以用来运行Play应用

这些应用服务器经过测试是支持Play 1.0.2的，但其他版本尚未经过充分测试。

 

JBoss 4.2.x	JBoss 5.x	JBoss 6M2	Glasshfish v3	IBM Websphere 6.1	IBM Websphere 7	Geronimo 2.x	Tomcat 6.x	Jetty 7.x	Resin 4.0.5
✓	✓	✓	✓	✓	✓	✓	✓	✓	✓

 

数据库：

Play!内建了JPA的支持，内置了Hibernate作为默认的持久化引擎。 Play! 还内置了HSQLDB 数据库，支持内存数据库，非常方便做项目开发和测试。（目前Play默认使用H2作为内存数据库)

Play!的Controller采用命名约定：

<form action="@{Application.createUser}">
    <input name="name" />
    <input name="password" />
    <input type="submit" value="Create User" />
</form>

无需其他任何配置，Play!会自动映射form中的name和password参数至createUser方法。

View 层Play!使用以Groovy语法写好的html模板中去以render()方法的参数渲染，并将结果回传给客户端。

扩展性：
        开发人员可以编写插件(plugin)或模块(module)扩展Play的功能。目前，Play官方和第三方开发者提供了一些常用的模块

 

 

总结：

 

          在学习Play!的过程中，最经常的感受就是——简直太简单了！并不是说Play!是一个设计简单的框架，相反学习中发现处处都会发现Play!设计的完整，这种完整性甚至包括网站设计和学习文档。Play!的简单之处在于它学习和使用起来非常简单。使用Play!新建项目，所有的目录结构都会自动建立。Play!摒弃了传统的JSP +Servlet技术（这太伟大了），自己提供了一套非常易用的MVC 框架。 

  很多多java开发人员对ROR风格不屑一顾甚至根本不关注，不了解，也许是被sun+ibam下毒太深了吧？其实想想，spring的基于接口 bean管理的xml在很多时候也是写一次，到项目下线也未曾修改过。 

java本身也太过强调仅仅java语法层面上的通用，抽象，配置，甚至太OO了，在java诞生的时代，这种做法是很先进的，而当今web应用开发算是一个特定领域，这种不与时俱进，不考虑web开发实际特点的做法有点杀鸡用牛刀之嫌，必然打不过转为web开发场景设计的新的动态脚本语言。 java毕竟不是专为web开发设计的语言，随着时间的推移，java的身躯越来越笨重，版本升级很慢，期待jdk7加强对动态语言的支持:JSR292。但这还不够，就像ruby on rails一样，还得有一个rails框架支撑。

在中国，企业级系统至少一大半是比互联网线上产品还小的系统。特别是中国互联网公司的玩得还是硬气功，之内的企业级系统开发很多还是停留在一个人，两三个人搞定一个系统的层次上。那这样看来，就算有人认为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 本身支持插件机制。扩展应该也没问题。估计也一大堆可用的mokuia，这个很重要，：spring ，orm（应该也有Ibatis吧），lucene search，MongoDB，甚至Scala。都很不错。 

想在Model层用一下no-sq的话，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不适合多人协作开发，晕，门户网站千万级用户量的系统核心开发人员也不会超过5-8人。更何况，在多人开发的情况下也是尽量一人负责一块儿的，相反，现在好多开源框架恰恰过多考虑了不符合中国实际的多人协同开发场景，搞得框架分离得过于松散，过于流水线，搞得一两个人开发项目时，反倒觉得麻烦得要死。所以不适合多人协作开发好像也算不上什么缺点。 

ROR COC就是要改变java程序员妄图对一切应用都机械地力求基于接口编程，通用，显式配置才放心的习惯。大部分web应用开发只要做到webservice restful api层面上的面向接口编程，和通用性基本就足够了。不要忘了restful api本身已经是抽象得巨好的架构了。这样，web开发人员才可能提升开发效率，把时间和精力放到业务逻辑本身，这样才有敏捷开发的可能。想想，如果你的开发要点和时间都消耗在未雨绸缪，坐在椅子上凭空想象n年后的需求变更，而作所谓的基于接口编程，再加上缓慢的编译，部署，运行，怎么可能适应敏捷开发的要求呢？反而会导致一个项目虎头蛇尾，前期优雅得要命，后期丑陋得要命，都往action甚至jsp里堆代码了，何苦呢？反不如，一开始就低下你高贵的头颅，心平气和务实地去ROR了。 

总之，简单说，如果play!framework真的兼容了java与php，ruby等动态语言的优势，那就是目前java人员web开发最佳的选择之一。 

转载于:https://my.oschina.net/aiguozhe/blog/36450