轉：我眼中的JBoss Seam六大優勢和兩個問題（看到好東東當然要和大家分享）

一、Seam適應快速開發、簡化框架的趨勢

在RoR流行之前，Java社區的主流還是非常講究分層、架構、複用和模式，而比較忽視快速開發和簡化架構的，其結果就是代碼量大、開發週期長、架構相當煩瑣。以比較常見的Struts/Spring/Hibernate爲例，從大的分層來說就有Web層、業務層和持久層，從細的分層就從前到後有：View(JSP) -> Struts Action -> Spring Business Object Bean -> Spring DAO Bean -> Hibernate Persistent Object。如果有Remoting調用，那麼還需要相應的Service Facade層。每層都是用不同的技術框架或者模式、各層之間整合的方式也是五花八門。把整個項目的架構搭建起來，已經是非常麻煩的事情了。

Seam給我的感覺像是一個異常簡單的MVC框架，他實際上只有兩層：JSF View和 Seam Component。而Seam Component有兩類：一類是Entity Bean，另一類就是Session Bean。Entity Bean映射數據庫表，Session Bean完成所有的業務邏輯，包括可能的持久化，事務，響應頁面請求、商業邏輯，頁面流控制等等。配置文件也不多，除了一堆基礎的配置文件，唯一一個需要不斷修改的就是pages.xml了，即配置JSF的view映射。

所以Seam開發項目看起來很簡單、很直接，無分層之苦惱。相應的也會讓程序員把精力主要放在業務邏輯組件的實現上，而不是把精力浪費在架構、分層、模式和基礎設施搭建的工作上面。

二、Seam的數據綁定做的很出色

由於是一個簡單的兩層結構，View和Component之間的數據綁定做的很出色，看起來比我欣賞的Webwork的數據綁定方式更勝一籌。官方的說法叫做雙向依賴注入，在component裏面可以直接取到頁面提交的數據，在頁面也可以直接訪問component數據。

另外持久化數據的校驗也直接集成好了，在EntityBean裏面聲明數據的約束，在頁面就可以直接校驗了，和RoR的數據校驗方式是一樣的，當然這也得益於Gavin King是Seam和Hibernate兩個項目的作者的緣故。

三、Seam的組件機制看起來相當好用

既然Seam簡化了分層，實際上把主要的工作都推到組件層去完成了。但是Seam的組件層看起來很簡單，這得益於Seam的組件機制設計了很多的組件狀態，根據不同的組件狀態，天然的劃分了不同組件的功能和邏輯。

Seam的組件有點類似於把傳統MVC的Action和Spring的Bean合二爲一了，但還是不同於傳統的MVC框架下面的Action：傳統的MVC Action是基於頁面請求的，無法複用，而Seam的組件是事件驅動方式，它只需要捕獲和實現事件代碼就可以了，至於怎麼觸發它並不需要知道，他和Web層可以不綁定，因此理論上面來說是可以實現組件複用的。我個人認爲Seam的這個組件機制非常巧妙，既可以用來實現響應頁面事件，綁定頁面數據的所謂Web Bean，也可以用來實現和Web沒有任何關係的純業務邏輯組件，一個很漂亮的實現。

另外Seam的組件注入機制看起來也很簡單，不像Spring那樣麻煩，而且內置了很多現成的組件進來，直接用Annotation聲明一下就可以用了，感覺寫組件真的很方便、很靈活、很強大。

四、Seam把數據庫資源的管理和事務的封裝完全隱藏起來了

Spring的數據庫資源管理和事務封裝是通過提供了一系列的代理類以及配置文件來實現的，程序員還是要通過配置文件的方式來手工管理事務，訪問數據庫也必須通過Template編寫匿名內部類來實現，而且在Spring/Hibernate框架下面，OpenSessionInView是一個很討厭的問題。

但是Seam已經把數據庫資源的管理和事務的封裝全部都隱藏起來了，程序員完全不需要知道，也不需要操心這些事情，這真是個大大的解放。當然Seam可以做到這一點，也無非是因爲Seam提供了一套上至View層，下至持久層完整的框架，因此可以把實現細節隱藏在框架內部，不暴露給程序員。Spring之所以做不到這一點，也因爲他只充當了一個黏合劑，不能夠直接修改View層和持久層帶來的限制。

五、Seam對第三方框架的整合看起來比Spring更深入

原來印象當中只有Spring才提供了一站式的解決方案，這次一看Seam文檔，呵！發現Seam也都齊全了，什麼郵件啦、工作流啦、頁面流啦、規則引擎啦、異步任務調度啦、消息系統啦、Web服務啦、遠程調用啦、甚至全文檢索啦全部都集成了。而且集成的比Spring更深入一些，例如Java EE本身的JMS，MDB自然是Seam的強項，而JBoss自家的JBPM，JPDL，Rules集成的更加沒得說。

從整合角度來說，感覺Spring和Seam的出發點不同：Spring更像一個平臺，我提供整合的可能性，然後程序員你自家去整合，我提供一些寫好的整合bean，對於這些你通過XML配置一下就整合進來了，如果我沒有提供bean的，那麼你也可以自己寫bean來整合。而Seam更像一個完整的框架而不是平臺，我這個框架想提供的功能，框架自身就已經整合好了，你直接用就是了，你也可以自己寫擴展來整合，但是這個不是Seam希望程序員做的事情。

因此對於程序員的感覺來說，Spring給你提供了一切的零件和半成品，但你要自己動手來組裝，而Seam已經給你裝好了一個成品，你就別自己改裝了，直接拿去用吧。

六、Seam提供了方便的代碼生成器

和appfuse類似，可以直接用ant task來生成一個完整項目的骨架，以及相應的組件代碼生成器，利用seam-gen可以快速生成一個完整的、帶有AJAX功能的CRUD項目，而且還是一個eclipse或者netbeans工程，你可以直接用IDE打開編輯了。這功能雖然不太難做，但是對於程序員來說，幫助是很大的。Seam做的相當不錯。

以上是我對Seam的一點小小的讚許，當然我也有一點疑問：

一、Seam的View實現是JSF，看頁面代碼還是密密麻麻的Tag

我是非常反感JSP Tag的，看看頁面密密麻麻的Tag就頭皮發麻，能不能弄一個Template呀，例如freemarker啥的？這些Tag既不直觀，也不方便擴展。需要擴展頁面組件，總不能讓我自定義Tag去幹活吧？不清楚這個問題怎麼辦？像freeamarker還可以方便的自定義頁面宏呢。

二、每次修改都要重新打包發佈，太麻煩了吧

就算修改一個頁面，也要整個打包deploy成爲一個ear去拷貝到jboss的應用目錄下面，這個要是改頁面，不是得煩死？ 我以前都是在項目裏面直接內嵌Jetty，作爲一個application啓動，修改頁面根本無需重起呀，更不要說deploy了。

總體來說，我覺得Seam框架非常出色，尤其是他的組件機制設計的很有匠心，真不愧是Gavin King精心打造的框架了，雖然看起來還是有些缺陷，但是做企業應用項目的話，Seam是一個很棒的選擇，作爲程序員來說，要比用Spring/Hibernate/Struts省心的多，更能夠把精力放在業務邏輯的編寫上面，開發效率也很不錯，可能是Java開源框架裏面最優秀的快速開發框架之一了。

 

原帖地址：http://www.javaeye.com/topic/212105