Spring Roo 敏捷還是災難?

這兩天 Survey 了一下 Spring Roo,標榜 RoR 式開發

不過淺嚐的感覺不是很好,大概把自己的感覺描述一下

  1. 詭異的 AOP ,照官網的範例下去走,生出來的 entity 搭配了 4 個 aspect,如下所示

搞不懂為何要這麼多 aspect 不過我猜應該是要配合 roo 的原始碼產生機制,讓 roo 可以準確的將產生的原始碼插到正確的位置上。

  1. 前端的選項太少,配合的是 Apache Tiles,我熟的 Struts2 所以一時間看不懂前端的運作(我想這是我個人問題吧~)

  2. 新增物件的內一個屬性需要改這麼多東西

Managed SRC_MAIN_JAVA/com/foo/Timer.java Managed SRC_MAIN_JAVA/com/foo/Timer_Roo_JavaBean.aj Managed SRC_TEST_JAVA/com/foo/TimerDataOnDemand_Roo_DataOnDemand.aj Managed SRC_MAIN_JAVA/com/foo/web/TimerController_Roo_Controller.aj Managed SRC_MAIN_WEBAPP/WEB-INF/views/timers/list.jspx Managed SRC_MAIN_WEBAPP/WEB-INF/views/timers/show.jspx Managed SRC_MAIN_WEBAPP/WEB-INF/views/timers/create.jspx Managed SRC_MAIN_WEBAPP/WEB-INF/views/timers/update.jspx Managed SRC_MAIN_WEBAPP/WEB-INF/i18n/application.properties Managed SRC_MAIN_JAVA/com/foo/Timer_Roo_ToString.aj Managed SRC_MAIN_JAVA/com/foo/gwt/scaffold/generated/TimerListView.java Managed SRC_MAIN_JAVA/com/foo/gwt/scaffold/generated/TimerDetailsView.java Managed SRC_MAIN_JAVA/com/foo/gwt/scaffold/generated/TimerDetailsView.ui.xml Managed SRC_MAIN_JAVA/com/foo/gwt/scaffold/generated/TimerEditView.java Managed SRC_MAIN_JAVA/com/foo/gwt/scaffold/generated/TimerEditView.ui.xml Managed SRC_MAIN_JAVA/com/foo/gwt/request/TimerRecord.java

雖然說手工的話也要改那麼多,不過看到這樣,我都軟了。

  1. 疊床架屋不利新手,這一點就是 Java 的通病,以 MVC 模型來說,每個英文字母都有對應的一套 Framework 然而每個英文字母上的 Framework 又有多種選擇,難怪大家會跳船到 .Net,畢竟  M$ 提供給你的就是唯一的選擇。

結論

像是用工具產生的原始碼,基本上還是不要徒手去改會比較好。

一般來說簡單的 CRUD 所需的繁瑣工作可以交由 Spring Roo 來處理,至於生出來的前端可以當成後台來使用。至於要給人家看得前端還是手刻一個會比較好。

如果只是要快速生成一個不重要的系統來作一件不重要的任務的話(線上登錄發票抽獎之類的,或是下圖的披薩店後台),倒是可以考慮用 Spring Roo。

總體來說,Spring Roo 的確可以快速的開發 CRUD 型的網站,不過受限於工具的關係,要從簡單 scale 到複雜,可能有點困難,除非在一開始先把所有的 entity 開好,跟 entity 對應的 CRUD 自然會自動產生,之後就拋棄 Roo,像是把 Roo 當成程式樣板產生機,這樣的話,到可以省下一些繁瑣工作的時間。

Follow 院長與芊比媽 on Google News