Spring Roo 敏捷還是災難？
這兩天 Survey 了一下 Spring Roo，標榜 RoR 式開發
不過淺嚐的感覺不是很好，大概把自己的感覺描述一下
- 詭異的 AOP ，照官網的範例下去走，生出來的 entity 搭配了 4 個 aspect，如下所示
搞不懂為何要這麼多 aspect 不過我猜應該是要配合 roo 的原始碼產生機制，讓 roo 可以準確的將產生的原始碼插到正確的位置上。
-
前端的選項太少，配合的是 Apache Tiles，我熟的 Struts2 所以一時間看不懂前端的運作（我想這是我個人問題吧～）
-
新增物件的內一個屬性需要改這麼多東西
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
雖然說手工的話也要改那麼多，不過看到這樣，我都軟了。
- 疊床架屋不利新手，這一點就是 Java 的通病，以 MVC 模型來說，每個英文字母都有對應的一套 Framework 然而每個英文字母上的 Framework 又有多種選擇，難怪大家會跳船到 .Net，畢竟 M$ 提供給你的就是唯一的選擇。
結論
像是用工具產生的原始碼，基本上還是不要徒手去改會比較好。
一般來說簡單的 CRUD 所需的繁瑣工作可以交由 Spring Roo 來處理，至於生出來的前端可以當成後台來使用。至於要給人家看得前端還是手刻一個會比較好。
如果只是要快速生成一個不重要的系統來作一件不重要的任務的話（線上登錄發票抽獎之類的，或是下圖的披薩店後台），倒是可以考慮用 Spring Roo。
總體來說，Spring Roo 的確可以快速的開發 CRUD 型的網站，不過受限於工具的關係，要從簡單 scale 到複雜，可能有點困難，除非在一開始先把所有的 entity 開好，跟 entity 對應的 CRUD 自然會自動產生，之後就拋棄 Roo，像是把 Roo 當成程式樣板產生機，這樣的話，到可以省下一些繁瑣工作的時間。
