Seam生命周期

嗨,在中国,国外的新技术出来N年之后,中国才掀起浪潮是很正常的事情.

我也发表一下我的看法：

1、seam 复杂也是因为集成了很多组件显得复杂，但是当你掌握了以后他的编程模型也很简单，核心IOC这一块谁都这么用，复杂的东西你可以选择不用。
2、seam 启动慢，占用内存多，spring 未尝不是这样？
3、richfaces平心而论，用起来简单，优化起来真难。我在项目中用richfaces也是最多，都是企业项目，如果是展现性能要求比较高，我肯定不会用richfaces。
4、seam服务器端的效率限制也是conversation会话周期效率会受影响，但你有没有想过，真是这个会话周期给你省了多少的事？
5、完全没感觉到，做了很多项目，很多时候都是用的问题。

我觉得seam的强项在于企业开发：表多，表间复杂逻辑操作不是很多，程序并发量小，这种情况下开发效率占主导因素，seam优势比较大。集成组件丰富，使用简单。

如果现在有新项目，还是宁愿不要使用seam，而使用Java EE 6，如果要使用seam也是使用seam3，就是模块化的,Java EE 6兼容的版本。千万不要使用seam2了。对于已经有的旧项目，要么迁移到seam3上，要么换成其它的基础框架吧。这样的结论才是有现实意义的。

只能说你在瞎扯了。seam3 经过实践检验了么？seam2 经过那么实践检验，怎么说。

结论过于武断。技术的高低不是决定项目的成功与否，使用技术的人才是关键。

我们spring，struts 2，spring mvc，seam 都用，我从来没有感觉到技术的重要性或者复杂到你行我不行的地步。

从来都是业务复杂，需求变更，软件质量管理，测试等耗费更多的精力。

有一句话是爱之深，责之切。seam我的最久，感情也更深，他的缺点我从来都不回避，我有时候做梦都想梦到一个效率奇高，使用简单的ajax 前端，可惜我没那本事，也没那精力。利用好技术的长处，做好手头的工作，足矣。如果有空闲的时间，多和seam，或者其他自己喜爱的技术社区互动，对自己的提高也不无裨益。

我们讨论seam什么的不是很好吗？为什么要搞人身攻击呢？你说我瞎扯，我说你胡扯，那这样的讨论还有存在的意义吗？请注意你的态度。

seam2这个开源项目已经停止更新了，都转到新的seam3上了，如果现在有新项目，何必非要搭这个明日黄花样的老车呢？seam2经过实践检验了，但至少在我们这里没有通过检验，我个人的观点，就算乘老车，也不要乘seam2这样的破车。seam3到底在实践中会表现如何我不知道，但是从它的设计来看，至少它模块化了，你可以只要jsf2 + weld，而不选择使用其它模块，集成的东西少了，自然出问题的机率也会变低。再者seam3也符合java ee 6标准了，这样你可以保留选择标准的哪种实现的权力，这不是很好吗？就凭这两点seam3也是可以尝试的。

我觉得与seam2 seam3相比，以spring为核心的基础架构这些年来不仅使用的人多，而且口碑也好，并且还在持续的更新中，所以我才觉得保守一点还是使用以spring为核心的基础架构好了，不要轻易尝试seam。

我承认业务，需求等等很多时候比具体实现技术重要，但这并不代表我们不需要对实现技术进行挑选和改进。特别对于一个多人协作的，长期运行维护的项目，实现技术的选择并不可忽视。

你爱也好，恨也好，是你个人感情的事，我尊重你的感情，就算你为了seam献身，我也只会送去尊重的目光，但是当我们谈论这个技术本身，当我们的评价会影响到别人的决策时，我不仅要尊重你的感情，还要尊重别人的利益。因此，正如我尊重你对seam的爱一样，你也应当尊重我对seam的恨。把我们的爱恨都展现，让每个决策者自己去评判。