22 April 2006

Wicket 的開發相當有活力,現在已經是 SourceForge 前 100 的 Project 了。長遠來看,更新和支援應該不是問題。那,現在呢?現在該不該導入 Wicket 呢?

下面總結一些 "我" 認為 Wicket 不適用的場合

  • 當網站偏向 Web site,而不是偏 Web app 時,Wicket 不適用。所謂偏 web site 是指網站的內容多半是靜態的文章,例如 News, Forum, Blog, Wiki 等等 CMS 的系統。偏 web app 是指有很多動態的功能,UI 互動很多的網頁,例如網路 ATM 或是一般的購物車。如果你的專案是將 desktop app 搬上 web,那也多半是屬於 web app,因為有很多複雜的互動。這種 app 才能從 Wicket 上得到好處。
  • 當網站需要 fail-over cluster, 大量 session-replication 時,Wicket 不適用。Wicket 為了讓程式開發簡單,所以使用很多 session 的資源,這個在 fail-over cluster 環境下很吃力。當然 Wicket 也有提供很多地方讓你調整啦,但是如果你的網站一開始就要 fail-over,然後資料又多,Wicket 並不是好選擇。這裡要說明一下 fail-over 是 cluster 最複雜的 strategy,其他的做法還有一個是 Sticky Session:這種作法沒有 session-replication 的問題,也能達到 load-balance。如果你採用的是 sticky session cluster,Wicket 也是可以適用的。另外市場上還有 JVM Cluster 這種神奇的產品,Wicket 配這個應該也是不錯。
  • Team 裡面沒有熟稔 Open source 的工程師,換句話說,如果沒人可以自己爬 source,上 mailing list 討論,看苦澀的 Javadoc。那麼 Wicket 現在不適合在你們的 team 內導入。原因是 Wicket 現在太年輕,而且成長太快,造成 API 並不是很成熟。這個情形會再夏天後第一本書 ( Wicket in Action ) 出了之後,才會 "稍微" 改進。呵~ 為什麼用 "稍微" ? 就我對 Wicket 主要 commiter 的觀察,他們在實作新 idea 或是使用者需求時,通常很快就加進去,而且不大忌諱修正 API 。這樣的好處是這個 framework 能較快的適應市場的需求(比方說現在 AJAX 紅,很快就加了 AJAX 的功能),但缺點就是 API 較不穩。再過個半年、一年後應該就比較沒這個問題了。

以上是 "現階段" 的情形,Wicket 的 commiters 也不斷的再解決上述的問題。如果你現在不符合上述的任一情形,那麼現在就可導入。Wicket 除了上述狀況下,就我所見其他功能皆大幅優於其他 framework。導入後不久就可看到生產力提升的成效 (或是做到原本做不到的功能)。

最近這兩週我們內部做了兩次的 Wicket 訓練 (二天),組員學完後的感想是 - 比 Struts 好用太多了... - 然後爭相尋問現有專案或是新專案可不可以趕快導入... ;-)


回響

可以用 Tag <I>、<B>,程式碼請用 <PRE>