關於Play（Play 2.0 介紹）

Play 2.0 介紹

2007開始，咱們一直致力於讓Java開發web應用更容易。Play始於一個內部項目Zenexity，它深入影響了咱們開發web項目的方式：關注開發者生產力，遵循web架構的特色，並打破常規，使用新的打包方式－－所以稱爲JEE最佳實踐是有道理的。

2009年，咱們決定在社區中以開源項目的方式分享成果。該舉動當即獲得了極積的關注與反饋，項目也愈來愈受歡迎。現在－－通過兩年的活躍開發 － Play已擁有多個版本，創建了一個4000多人的活躍社區，愈來愈多的應用被部署於生產環境。

開源分享意味着會收到更多的反饋，也意味着能發現和學習更多的新用例，新特性，和在原先的設計中忽視的潛bugs。兩年期間，咱們修復了某些問題，同時增長了某些新特性來支持更普遍的場景。伴隨項目的成長，咱們從社區和自身的經驗中學到了不少不少 －－ 正在使用Play部署更復雜更大型的項目。

同時，技術和web也在持續發展。web已經變成全部應用的中心。HTML，CSS，JavaScript的技術也在快速變革 － 幾乎使得服務端框架跟不上步伐。幾乎全部web架構都在迅速的向實時應用靠攏，SQL數據庫再也不是數據存儲的惟一選擇。而在開發語言層面，咱們也目擊了一些鉅變，基於JVM的語言，包括Scala，正日益普及。

        這就是Play 2.0項目誕生的緣由，一個新時代的新web框架。

 構建異步應用

現在的web應用正在整合更多的併發實時數據，所以web框架必須支持完整的異步HTTP編程模型。Play最初是設計來處理經典的短暫web請求。但如今，事件模型可用於處理持久鏈接 －Comet, long-polling and WebSockets.

Play 2.0 一開始就基於一種假設構建，及每個請求都是潛在的長鏈接。但那不是所有：咱們也需具有一種建壯的方式分配和運行耗時任務。Actor-base模型處理這些高併發情形，當仁不讓，而該模型的良好實如今Java和Scala語言中則是Akka－ 他來了。Play 2.0爲 play 項目提供了原生的Akka支持，能夠編寫高度分佈的系統。

關注類型安全

使用靜態類型語言開發play應用的目的之一是使得編譯器可以檢查你的每一個代碼部分。這不但使得查錯更方便，也使得多人協做的大項目流程更順利。

Play 2.0 加入了 Scala 的支持，咱們清楚的知道這會從更強大的編譯器中受益 － 但這還不夠。在 Play 1.x 中，模版系統是動態而基於groovy的，編譯器查錯能力有限。這使得模版中的錯誤只能在運行階段發現。控制器驗證的膠水代碼也是同樣。

在2.0版本，咱們推薦，讓編譯器在編譯階段檢查你的大部分代碼，這種觀點。這就是咱們改用Scala作爲默認模版的緣由 － 甚至對於那些以Java爲主要語言的開發者。這不意味着你必須是一個Scala專家才能使用 Play 2.0 的模版，就像你沒必要精通groovy也能使用 Play1.0 的模版同樣。

在模版中，Scala主要用於遍歷你的對象視圖顯示相關信息，並使用相似Java的語法。然而若是你想充分發揮Scala的能力試圖編寫高度抽象的模版的時候，你很快會發現，Scala，作爲一門函數式語言，爲什麼可以完美支持模版的緣由。

這並非模版引擎的所有：路由系統也是類型安全的。Play 2.0也會徹底檢查你的路由文件，驗證路由聲明，包括路由反向引用的部分。

所有靜態編譯的另外一個好處是模版和路由規則能更容易的打包和重用。你也能夠在運行時得到顯助的性能增益。

    原生支持 Java 和 Scala

在Play的早期版本中，咱們就開始探索Scala開發play應用的可能性。咱們一開始之外部模塊的形式支持Scala，能夠自由的進行試驗而不影響框架自己的打包。將Scala與基於Java的框架集成並不容易。鑑於Scala和Java的兼容性，咱們天真的認爲，能夠迅速的實現集成，使用Scala語法代替Java語法。然而，這並非使用該語言的正確方式。Scala是一門面象對象與函數式混和的編程語言。充分發揮Scala須要重寫大部分框架APIS。

咱們很快就到達到了外部模塊支持Scala的瓶頸。在Play 1.x 的最初設計選擇，咱們使用了大量的Java反射api和字節碼加強機制，不徹底反思Play內部結構的話，會很難進展下去。同時咱們也爲Scala模塊開發了一些很棒的組件，如新的類例安全的模版引擎和新的SQL訪問組件分支Anorm。這就是咱們決定，在Play中徹底釋放Scala的能力的緣由，咱們已將該外部模塊遷移到框架內部。

另外一方面，在 2.0 版本中咱們不會減小對Java的支持力度。偏偏相反，Play 2.0 的構建對Java開發者提供了一個增加經驗的機會。Java開發者能夠真正的沿用它們的經驗。

    強大的構建系統

在Play項目伊始，咱們就選擇了新的方式運行，編譯與部署項目。一開始這看起來像深奧的設計，關鍵點是提供了一個異步的HTTP API替代標準的Servlet API，在開發階段經過實時的編譯和重載源碼得到快速的反饋週期，促生了一個新的部署方式。因此，很難讓Play遵循標準的JEE規範。

現在，輕容器部署在java社區中已深刻人心。這是一個讓Play框架原生運行於像Heroku這類平臺的機會，一種設計選擇是讓Play框架原生運行於Heroku這類平臺中，它引入了一種模型，咱們認爲這是Java應用將來部署於PaaS平臺的方式。

然而，現有Java構建系統，不能靈活的部署。既然咱們要提供一個更簡單直接的工具運行和部署Play應用，在Play 1.x 中，咱們提供了一系列的Python腳本處理部署任務。

同時，開發者們使用Play開發更多企業級的項目，他們須要自定義的構建流程，並與公司現有的構建系統集成，開發者爲此感到有些失落了。Play 1.x 中基於Python的構建系統已力不從心。所以咱們決定爲Play2.0開發一個全新的更強大的構建系統。

既然咱們須要一個先進的構建工具，須要足夠靈活的支持現有的Play環境去構建Java和Scala項目，咱們選擇將sbt集成進Play2.0。然而，習慣於Play舊的構建系統的用戶不要被嚇唬住，咱們保留了一樣的 play new,run,start 模式。

Play2.0帶來了一個預處理構建腳本，可以爲大多數用戶良好工做。另外一方面，若是你想更改應用的構建和部署方式，事實上Play項目也不過是sbt的一個標準項目，給了你按需自定義的能力。

這也意味着能與外部Maven項目更好的集成，它能將你的項目以jar文件打包發佈到任何倉庫中，並在開發階段被依賴的項目實時的編譯和重載，甚至是標準的Java和Scala項目。

    數據存儲與模型集成

‘數據存儲’再也不是‘關係數據庫’的代名詞，可能歷來都不是。不少有趣的存儲模型開始流行，它們爲不一樣的場景提供不一樣的特性。這種狀況下，像Play這樣的web框架，想提早假設開發者將會使用的各式各樣的數據存儲機制，會變得很困難。一個通用的模型概念再也不靈光，它不可能將如些衆多的存儲技術抽象成統一的API。

在 Play 2.0 中，咱們想讓各類數據存儲驅動，ORM或其它的數據庫訪問層，更容易集成在一塊兒。咱們只是想提供一些小工具集來解決常見的技術問題，像管理鏈接池。咱們也想，爲了保持Play全棧式框架的優勢，照顧那些沒有特殊需求的用戶，默認綁定了訪問經典關係數據庫的工具，所以，Play 2.0 提供了一些內建的關係數據庫訪問框架如Ebean,JPA和Anorm。