滿江紅開放技術研究組織釋出Seam 2.0中文文件RC版

　　"你得知道，我想的比做的更多。如果你要做一個開源專案，必須設想好它的道路，它才會成功。"Gavin King這麼說過。那時候他已經在新天地luna酒吧灌下大杯的法國葡萄酒，還要裝作若無其事。不得不承認這個傢伙相當聰明且自負。他做出的決定是深思熟慮的。

　　B/S程式和C/S不同，Request/Response模型讓程式冗長的像裹腳布。你同時要處理多種資料失配：伺服器端的RDBMS和瀏覽器展示出來的HTML之間，需要Servlet的渲染，資料經歷了RDBMS Row ，ResultSet, 若有若無的DTO和瀏覽器Form資料這幾個步驟，讓資料變得支離破碎。實際上所有的Java框架的核心都是解決不同層面的這些破碎。Hibernate解決的是DTO和ResultSet之間的破碎。和大多數初學者認為的Hibernate是一種物件導向的ResultSet包裝器的字面理解不同，Hibernate的目的是對RDBMS資料的便於進行快取的細粒度切割，"物件導向"只是工具而非目的，快取才是一切的本質，它讓Hibernate真正成為了具有強大戰鬥力的武器而非可笑的物件封裝器。

　　解決了這一失配後，Gavin King把目光放到了HTML Form和伺服器物件之間的失配上。這一次的目的是簡化，儘可能的簡化，因為對Web程式設計而言，最大的瓶頸是開發效率，因此Seam的目的就是最大限度的簡化複雜性。這一次的戰線要比Hibernate寬廣的多，Seam的好處因而也更加讓人看得明白：它提升JSF的實力，讓快速開發效果豐富的Web應用程式成為可能。從雙向注入到Annotation，目的都是為了儘量減少伺服器端的程式碼量，而RichFaces和JSF編輯器，則是為了讓Seam的產出變得效果豐富。

　　但顯然，HTML Form的表現力和可能的複雜性遠遠超過ORM中物件的關係的種類，因此，任何針對HTML的元件封裝都必須以其高品質才能讓使用者感到信服。作為整合開發工具Seam的道路還很長，對Grid等複雜元件的支援尚不夠，讓2.0仍然無法達到Delphi在Windows開發界的廣大影響力。換句話說，JSF的未來，在於其是否能成功的製造出元件產業鏈，一方面真正簡化開發者的勞動，提高效率，另一方面讓元件開發者能把經精力集中在開發高質量的元件上。在製造產業鏈這一目標上，JSF是領跑的，而JSF框架中，Seam是領跑的。

　　因此，你應該花些時間來看看Seam。

　　來吧，在這裡[url]http://wiki.redsaga.com/confluence/display/SeamRef/Home[/url]