Play Framework總結性介紹
顛覆臃腫的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服務器。
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作為持久化，并且使其更方便使用。個人意見：這段代碼倒是直接將持久層和表現層直接耦合在一起，沒看到Domain Model了。看來DDD需要普及到每個角落不容易啊。）
8、整合了緩存支持，可以使用memcached作為分布式緩存。
9、融入了OpenID 這樣單點登錄SSO技術。
10、提出組件重用，可以重用各種組件，包括CSS Javascript
個人點評：總體來說，Play框架是一個與Struts2 JSF Tapestry競爭的框架，但是又整合了持久層和服務器。
業務系統市場分析：
90%的web業務開源系統都是php版本的，特別是新興產品的開源實現，java的身影幾乎銷聲匿跡了。可惜j要ava出身的人去閱讀php風格的代碼簡直是一種受虐。這其實說明一個道理，java優美的架構還是很有價值的。但優美+務實的平衡才是最佳選擇。
框架對比：
運行方式與服務器兼容性：
Play 應用可使用這么幾種方式運行：標準Servlet容器、獨立服務器、Google App Engine、Stax 云計算平臺，等等
你也可以將應用發布到標準的應用服務器上執行，大部分應用程序支持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 Framework 框架中用到所有的 jar 包的集合，位于 {play}/framework/lib 目錄
Play! Framework 是07年的一個項目，08年開源，09年11月25日發布了1.0版。發布后我就一直在學習這個框架。現在正式發布版本已經是1.01版，而且1.1版本也在每日更新。可以在http://download.playframework.org 下載已發布版本，和每日的最新版。
bc. # Additional modules
# ~~~~~
mdoule.gwt=../gwt
module.cms=../cms
module.forum=../forum
module.directory=../directory
學習Play!的過程中，最經常的感受就是——簡直太簡單了！并不是說Play!是一個設計簡單的框架，相反學習中發現處處都會發現Play!設計的完整，這種完整性甚至包括網站設計和學習文檔。Play!的簡單之處在于它學習和使用起來非常簡單。使用Play!新建項目，所有的目錄結構都會自動建立。Play!摒棄了傳統的JSP,Servlet技術（這太偉大了），自己提供了一套非常易用的MVC 框架。Play!內建了JPA的支持，內置了Hibernate作為默認的持久化引擎。
Play! 還內置了HSQLDB 數據庫，支持內存數據庫，非常方便做項目開發和測試。
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()方法的參數渲染，并將結果回傳給客戶端。
外界介紹：
Play!雖然使用簡單，擴展性卻非常強大，篇幅所限所述不能詳盡。http://www.playframework.org 是Play!的官方網站，推薦大家到這兒看看。Play!的文檔非常詳細，教程中有份手把手做一個Blog引擎的教程，相信照著做一下之后一定會讓你學會Play! Framework，那時你一定會愛上她的！
貌似正常的開發流程，總要面對項目原型構建的問題，重新發明輪子，或者把以前的家伙式兒再搬出來reuse一下？此時此景，都不是最佳選擇。
90%的web業務開源系統都是php版本的，特別是新興產品的開源實現，java的身影幾乎銷聲匿跡了。可惜j要ava出身的人去閱讀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+ibam下毒太深了吧？其實想想，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層用一下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開發最佳的選擇之一。
原文鏈接：http://vanadiumlin.iteye.com/blog/947046
【編輯推薦】
