发现JBoss Seam很棒呀！有用Seam做过项目的吗？

“在RoR流行之前，Java社区的主流还是非常讲究分层、架构、复用和模式，而比较忽视快速开发和简化架构的，其结果就是代码量大、开发周期长、架构相当烦琐。”

分层，架构，复用，模式为了构建有弹性的应用，从软件的整个生命周期来看会减少很多各方面的成本。不同规模的问题采用不同的解决方案，如果只是构建一个十分小的应用不用任何框架使用 jsp+servlet 最简化。jsf本事就是一个败笔“灵感”来自asp.net，但是在vs里随便用鼠标点两下就能实现数据绑定，jsf能行么。ejb就更不用说了，天生就是为分布式应用设计的，本质上就是解决大问题的，他的复杂性相信大家都有所了解，国内有几个项目是基于ejb的，北京满大街跑的程序员有几个会ejb有几个想学ejb。
        ejb运行于庞大的java应用服务器但是这个seam偏偏说自己擅长解决轻量级问题这本事就是十分矛盾的。
     也不知道这seam能走多远。

看了半个月的seam，但还是不敢用来做项目：（

seam & jsf 毕竟是一种快速开发（RPD）框架，并不是java web开发的主流方向，作为sun来说，只是用来填补“asp.net模式”的空白，关于javaweb的未来已经预测到会放弃客户端，别说jsf，“银光”都放弃了

jsf从来都觉得会性能问题，把所有的性能开支都放在服务器端；说实话别是把精力放在框架上呢，ssh的方式够用了，用新的功能就升级呀

个人觉得seam耦合性高了一点。

看了1个小时才看完；有没有人说说seam中更适合领域模型啊

构建在JSF之上，就注定慢了...
除了表现层，其他都蛮不错

JSF技术是server side的状态。命中注定不能用于高负载的internet site。
企业复杂应用的快速开发倒是很好。不过这个时候偶觉得echo gwt之类的技术更合适，用java写出web界面。更快。

个人鄙视一切手工写html方式，不易于维护扩展。除非有很好的IDE支持。

疑惑一：JSF其实也仅仅是个规范而已，Tag自然有Tag的道理，从长远来看，以后的client不一定只是浏览器（能够识别html），如手机设备等，JSF的好处即是：如果你采用了JSF规范实现的tag，可以替换相应的render-kit既可以输出适应不用client的界面，具体可以阅读一下JSF Spec；

疑惑二：这个问题是不存在的，我用seam已有将近1年的时间，开发环境是eclipse，修改页面会自动deploy，无需重启server，当然我没有使用EJB3，而是pojo component+JPA（hibernate）


总的来说，seam确实方便灵活，seam还有很多精妙的地方楼主还没有提到（如seam的component在运行时被override的特性），但由于seam是一种全新的思路，而且整合了一些最新的spec，一般人刚开始时都难以上手和理解，所以我们要勇于打破常规和勇于否定，在驾驭这些框架或平台之后，我们需要思考的就是如何应用到我们实际的项目中去为用户解决实际的问题。 今天时间来不及，等我下次有机会再和大家讨论一下有关seam的一些心得。

我粗浅研究过seam，感觉太重量级，我尤其不喜欢ejb。我2001年的时候被ejb1.0和后来的2.0搞得焦头烂额。现在的3.0虽然简单了很多很多，但是实在没有必要在发布时搞成EAR，直接POJO+ManagedBean多简单啊。

如果不用ejb，那seam就没有用的必要了。所以我们现在的组合是(JSF+facelet)+spring+hibernate。我觉得相当地爽，JSF+facelet页面很漂亮、模板化很出色，数据双向绑定很简单。spring里面的东西也很简单，基本就是自动生成的DAO。

前面很多网友提到jsf慢的问题，以我的经验来看可能不一定如此。我用jsf做过一个项目，这个项目是将原来的桌面程序改成Web方式，所以用户对系统反应速度的要求极其苛刻。

系统刚开始的时候确实有点卡壳，后来发现是jboss的rich faces引起的，我们废掉了rich faces的界面控件后速度大大提升，基本接近桌面程序了。

当然期间还有许多的优化措施，比如js缓存、数据库端优化等等。以我的经验判断，jsf是会多占用一些服务器端的内存，增加一些计算。但是，我们自己编写的垃圾代码大多数情况下比 jsf影响更大的多！