現今就Web快速開發框架而言,有著許多的選擇,各自分布在不同的語言生態系之中,除了老牌的Rails、Django,還有Play!、Grails、Express、Spring Boot等框架,就架構與主要元件而言,這類框架其實十分相似,然而想要快速開發或是維持設計的簡單與一致前,弄清問題邊界與各自經驗,才有可能真正運用這類框架快速開發。

Web開發至今已經累積了相當多的成熟經驗,就Web應用程式而言,MVC已經是公認且驗證的架構,Web快速開發框架基本上必然實現了MVC架構(儘管有些細節上的不同),多半要具備的元素有URL路由對應、HTML模版系統、ORM與資料庫管理、表單處理與驗證、使用者管理、基本安全管理、測試、部署等;而附帶的元素,則為各種工具、程式庫(如郵件發送、多國語系時區支援)等,其中路由、模版系統與ORM,通常是一開始使用時最先接觸也最關心的部份。

URL路由對應基本上是個模式比對,乍看沒什麼,然而不同應用程式可能會有不同的路由設定方式,因而路由設定規則通常也是最複雜的,在各框架之間的設定方式也多半不一致,有些框架使用自行設計的表達式,有些框架使用規則表達式(Regular expression),例如Django;有些框架直接支援RESTful路由設定,例如Rails;有些框架必須外掛其他plugin或框架,例如基於Django的Django REST framework。

在HTML模版系統的部份,有些框架使用有別於原本程式語言的模版語言,像是Django,有的框架則可內嵌原本程式語言,像是Rails就使用了內嵌Ruby程式碼(Embedded Ruby),這會讓撰寫HTML模版比較不會在兩種語言間混淆,可以降低學習成本。

跟模版打交道時,標記的易用性也是很大考量,像是標記是否複雜或獨特,更重要的是避免與HTML衝突,像是使用了<、>來標記的話,有時就得自行Escape,以免與HTML標籤衝突,基於Java的Web框架,就有這類的問題。

Web快速開發框架無一不採用ORM來存取資料庫,不用撰寫SQL而藉由物件導向方式來操作關聯式資料庫,省去了物件導向與關聯式模型兩者間對照的繁瑣,框架搭配的ORM在API上通常都考量了大部份的需求,使用上並不困難,比較要注意的部分,反而是有無資料庫遷移(migrate)的功能,也就是能記錄資料庫表格變更歷程,未來可依記錄變更或回復資料庫表格欄位等內容,例如Rails、Django 1.7中就內建了遷移功能,而Django 1.7之前的版本,必須使用外掛south才有此功能。

語言、生態系特質

各個框架基於各自語言之上而建立,因而選擇框架的主要原因之一,當然,就與打算採用何種語言來開發,有高度的相關性,訴求快速開發、簡潔與靈活度的框架,多半採用動態定型語言實現,例如Ruby、Python與JavaScript之上,各自有Rails、Django、Express等代表框架,而基於JVM的框架,也有基於Groovy的Grails這類的框架,不過,也有基於靜態定型語言且同樣訴求快速開發、簡潔與靈活度,像是基於Scala的Play!框架。

不過,簡潔與靈活度在不同語言擁護者中,有不同的定義,就基於Ruby的Rails來說,由於有Ruby強力的meta-programming支持,在塑造相關DSL時特別有利,許多開發者甚至是學了Rails才回頭學習Ruby,證明了Rails在DSL上的表述力極佳,加上有慣例勝於設定(Convention Over Configuration, CoC)的原則,開發時能極大加快開發效率,不過,卻也容易因為不熟悉慣例或者DSL的相關魔術,而產生種種問題。

相對之下,由於Python社群崇尚明確(Explicit),沒有過多的魔術,程式碼雖然會多了些,然而,學習與使用過程卻也明確許多。

就語言生態系來說,由於Rails受到注目,才帶動了對Ruby這門語言的關注,因此Ruby社群幾乎是著重在Web開發這塊,單就Web生態這塊來說非常豐富,許多功能也被整合入Rails之中,然而缺點就是越來越臃腫;由於Python本身在Web快速開發興起之前,在其他領域已有相當之發展,Django本身自成一套生態系統,雖不若Rails那麼包山包海,然而學習負擔上比較輕鬆,不過在必要的時候,就得自行整合相關plugin或程式庫。

基於JavaScript/Node.js的生態系是比較特別的一群,由於JavaScript引擎不斷在效能上做了改進,加上採用非同步開發模型,像Express這類框架,效能上擁有很高的表現,擁有各種支援非同步程式庫也是優點,缺點就是多數開發者對非同步模型不熟悉,需要時間適應,JavaScript語言本身的缺陷也是問題(儘管Node.js持續努力實現ECMAScript 6)。

效能、文件、部署、升級

儘管各快速開發框架效能都會宣稱,經由某些適當設計或調校,效能不會是問題(另一常見說詞則是,語言速度不等於框架與應用程式整體速度),然而,當網站需要考量到效能因素時,動態定型語言實現的快速開發框架經常在效能上就捉襟見肘,這時儘管基於靜態定型的框架靈活度或簡潔性較差,然而速度上的優勢就具有彌補的作用,就這點來說,Rails比較可憐,談到快速開發框架效能不彰,總是舉得出從Rails遷移到其他框架的案例。

就我個人來說,選擇快速開發框架的重要考量還有個重要考量,那就是文件的齊全度,其中最重要的是官方文件,一個快速開發框架,卻要讓開發者在瞭解它的過程花費大量時間,對我來說是很不可思議的一件事。最重要的不是那種說明個別功能如何設定的文件,而是功能如何逐步加入應用程式,將之整合在一起的文件,像是Django官方的〈Getting started〉(https://goo.gl/Qy5H8m)文件就是個不錯的例子,就這點來說,Spring Boot就很差,嗯!或許他們的想法是,開發者得先學會整個Spring Framework再來用Spring Boot吧!

網站最終要上線,部署難易度也是得考量,現今雲端時代解決了部份問題,例如已有不少PasS(Platform As A Service)雲端方案,可提供特定語言框架環境,讓問題減少到考慮主機效能與價格彈性。

快速開發框架往往也是改版快速,因而日後版本升級的難易度也是必要考量,這大概也就是為何,快速開發框架都會將測試框架整合在內,平時有撰寫測試的習慣,有越完整的測試覆蓋,升級時對付新變化要花費的時間就會比較少,評估框架時記得查看過去的釋出版本,有無提供清楚的升級指南。

開發經驗與框架熟悉度

快速開發框架由於封裝了許多複雜的底層,經常被作為程式新手入門Web開發之用,然而,就個人的觀點來說,程式新手拿這類框架來學習入門,或者是寫些原型程式是可以,不過這類框架要拿來開發實際產品,應該要有Web相關開發經驗的人來使用,例如就連DHH本人也說過,Rails不是給初學者使用的(https://goo.gl/FCgjyn)!

因為就有Web相關開發經驗的人來說,在有足夠文件前提下,上手這類框架並不難,經驗上會告訴他們,MVC、RESTful、ORM等各是什麼,在某些魔術自動起作用的同時,也會去思考或探索背後的原理為何,這類框架的易用性,是建立在開發者已有相關的經驗之上,實際上,上手框架是一回事,真要能使用這類框架做快速開發,像是想在十分鐘內從無到有建立、修改出一個適用的BLOG,也得時時與框架為伍,加上足夠的開發經驗才有可能。

或許最好的評估方式,就是各自寫個原型實際評估,像是〈Play vs. Grails Smackdown〉(http://goo.gl/euYPYM),就開發過程可能使用之元素、語言、生態系、效能等各方面做評估,找出適合自身或團隊特質的方案!

作者簡介


Advertisement

更多 iThome相關內容