"你得知道，我想的比做的更多。如果你要做一个开源项目，必须设想好它的道路，它才会成功。"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。

　　来吧，在这里http://wiki.redsaga.com/confluence/display/SeamRef/Home