敝人曾在不一樣項目中使用JSP-Servlet、SpringMVC,Play2以及JFInal作過WEB開發,對每一個框架的易用性和可擴展性都有必定的瞭解。我也經常會思考這樣一個老生常談的問題:如何選擇一個合適的WEB開發框架?如今從我我的的實踐體會上來簡單的談一談。java
1、SpringMVCsql
SpringMVC最讓我感到興奮的是URL映射以及參數處理,這用起來會很是方便實用!數據庫
@RequestMapping(value = "/v1/order/{dealId}/user/{userId}", method = {RequestMethod.POST, RequestMethod.GET}) public @ResponseBody WebResponse createOrderOld(@RequestBody OrderParam param, @RequestParam Long userid, @RequestParam(value = "medium", required = true) String client, @PathVariable Long dealId , HttpServletRequest request) { ......
從這個典型的例子上咱們來分析:編程
1)"/v1/order/{dealId}/user/{userId}":是URL訪問形式,其中"{dealId}"是一個可變參數,具備由"@PathVariable Long dealId"來接收;性能優化
2)method = {RequestMethod.POST, RequestMethod.GET}:限定了http請求訪問方式;併發
3)@RequestBody OrderParam param:Spring會解析http request body裏的JSON內容並自動轉化爲OrderParam對象,節省了咱們大量的編碼工做;app
4)@RequestParam(value = "medium", required = true) String client:medium是必須傳遞的,結果最終賦予client。框架
這裏僅僅列出來常見的這幾種使用形式,其餘的諸如格式校驗之類的限定你們可自行嘗試,再也不贅述。僅從這個方面看,SpringMVC作得確實比較便捷!但SpringMVC讓人詬病的地方是由於配置太多,這一點能夠經過註解的方式來緩解,同時Spring Boot也是針對這個問題作的改進和優化!異步
2、Play2性能
Play2能夠開發基於Java、Scala的項目,官網有建立項目的簡單介紹:
經過命令行便可建立一個標準的WEB應用模版,有點相似於ROR。整個項目的目錄結構以下:
其中app是寫業務邏輯代碼的地方,conf是項目集中配置點(系統參數、日誌、DB等),build.sbt相似於Maven裏的pom.xml,集中管理依賴的地方。
在conf/routes中,是對URL的集中配置點:
routes:
GET /user/login controllers.UserController.login GET /user/logout controllers.UserController.logout
單行、一對一的URL與Controller.Action的對應關係。
使用Play2開發可能並無想象中那麼便捷和容易上手,須要必定的學習。不過好處也是有的,就是可使用Scala來方便的實現異步、併發的應用,固然這是Scala的語言特色。
3、JFinal
JFinal是目前罈子裏最火的項目之一,我也用JFinal作項目開發有4年功夫了,整體上是小巧,很適合小團隊實用,是對Servlet的極簡封裝。這樣太簡單也會出現一個問題,就是要求對RD的編程素質比較高,不然編碼質量很難保證。
JFinal實現的MVC框架中,最吸引個人是Model層和DB實現,咱們能夠直接經過Db.sql("select *...")來操做數據庫,很直觀簡單!JFinal約定Controller裏定義的public void xxx()方法纔是一個真正的Action,這就須要咱們本身來處理參數,經過getRequest ().getParaXXX來獲取並校驗,徒增非核心業務的代碼量。
4、What are you looking for?
其實,從上面我對這幾個框架優缺點的分析可知,我理想中的一個簡單、易用、靈活的的WEB框架所應具有的品質有:
1)簡單靈活的參數處理:提供基於註解的實現並能夠自定義註解,像SpringMVC同樣;
2)直觀方便的DB處理:像JFinal Model&Db同樣,提供充血的Model、SQL再也不成爲一個配置項;
3)良好的性能:一個太寬泛的概念,但異步&併發是性能優化當中必不可少的手段,Scala下降了這一門檻;
4)剩下的業務實現就由RD來保證吧!
5、How should I do?
是繼續尋找仍是DIY?DIY也許是目前一個比較靠譜的方式,集合這些框架各自的優勢,而後作一個適合本身使用的微型產品也是一種成長和提升!