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
