[導入]初窺Ruby on Rails
?昨天一時興起就和許老師去新華文軒買了兩本RoR的書,準備這個寒假專供此道,如果順利的話,再用它做一個缺陷管理系統的demo出來。
?不過研究了兩天發現,直接從RoR入手似乎不是很妥當,應該先學好Ruby,接下來再Rails。不過書已經買了,就硬著頭皮搞吧,還好下載了一本Programming Ruby第二版,遇到不懂的可以查閱。
?說說這兩天來(準確的說是今天下午到晚上)對Rails這個基于Ruby框架的認識。
?首先它是基于MVC的,這個一點也不奇怪,那么就分開介紹吧
?控制器:
??前端控制器:因為和J2EE的實現機制不太一樣,所以前端控制器不向Struts中的ActionServlet那么明顯,初步估計是由public目錄下的dispatch.*組成的。雖然實現機制可能不同,但是做的事情大同小異。
??應用控制器:類似于JSF中的action,一個應用控制器中可以有多個行為(action)。按照Rails的命名規約,一個應用控制器類必須以Controller結尾,其中的每一個public方法都是一個action。action中可以調用模型進行處理,處理完畢后默認跳轉到action同名的rhtml頁面(視圖),也可以用redirect_to方法跳轉到其他視圖。
??
??(注:我看的書中并沒有區分前端控制器,和應用控制器,這里沿用了Struts中的叫法)
?模型:
??
??模型應該負責提供數據、封裝業務邏輯、必要時還需要數據的持久化。先看看在J2EE中模型的實現:
?
??方式1:EJB中的實體Bean
??優點:數據、業務邏輯、持久化功能全部提供,代碼少
??缺點:持久化功能不靈活,導致一些業務邏輯難以優雅的實現。需要大量配置文件
??方式2:JavaBean
??優點:簡單
??缺點:大量重復的編碼
??方式3:Hibernate中的PO對象+DAO對象
??優點:代碼少
??缺點:po和dao是分離的,導致“貧血類”,Hibernate自身對事物的管理比較弱。需要大量配置文件,映射對象關系時比較復雜。如加入Spring則會進一步增加代碼的復雜度
??可以看到,J2EE中各種模型實現都或多或少有自己的缺陷(其中我最看好的還是實體Bean,希望EJB 3.0能一轉2.0的頹勢)
??而在Rails中已經使用了ORM,與Hibernate比這個ORM不需要大量的配置文件,只需要遵守命名規約,并在代碼中映射對象間的關系。更像EJB 3.0吧。
??Rails中模型的優點在于將數據、業務邏輯、持久化功能放在一起了,并且借助于Ruby強大的繼承功能,你并不會覺得模型變得臃腫,甚至更加簡單。
??缺點嘛,自然就是剛學的時候有些摸不著頭腦,呵呵。
??據說Rails中模型還有一種實現方式,看到后幾章再說吧。
?視圖:
??視圖沒有什么好說的,雖然里面確實有一些新東西,比如類似于tiles的layout(布局),神奇般的獲取模型中的數據,可以用于取代標簽庫的helper等,不過這些特性并不至于令人瞠目結舌。
?總結一下,我覺得Rails也沒有什么特別神奇之處,當然可能是因為我還剛入門。目前為止最震撼我的是借助于ruby腳本,可以快速根據數據表生成應用控制器、模型、視圖(Rails的術語叫scaffold【骨架】),在很短的時間內完成一個CRUD的界面。但是J2EE下的AppFuse也能實現這個功能。
?直到現在我還是固執的認為Ruby的快速開發就在于它提供了更多的api和更多的復雜語法。當然,這是一種成見,希望把這本書看完后會對Ruby和Rails有更深的了解
文章來源:http://blog.sina.com.cn/u/4a5ca0240100075p