JSF的优雅 带来的项目成本

推荐LZ用seam2+ejb3+icefaces

你会觉的开发也是种乐趣的.

不过组件扩展还是很令人头疼的.

1.自定义组件的开发的确比较复杂，需要深度了解jsf体系结构，但是它为开发高复用的业务组件带来了机会，对于开发组件的角色应该在公司是横切式的，不仅仅服务于一个项目。

2.我认为和旧的展现层框架比起来它为业务的良好封装带来了机会。

3.是否用简单的几句话就实现复杂的业务得看具体的设计，粗粒度的组件需要更高可用性的外部接口，组合式有时会胜过封装式。

4.感觉jsf不好的地方往往是因为规范带来的弊端，就是没有给出最良好的实践，seam集成jsf的目的基本是解决这样的问题。

5.细粒度的需求如果使用组合式会更好，有时是混合式。不一定要做一个自定义组件。

6.关注细节确实是jsf是否可以被接受的关键。

7.jsf实现的是框架而不是大包大揽的解决方案，客户的变态需要你的多变的解决方案，而不是依赖jsf组件来实现一切
8.往往费劲心思的开发一个组件，不如一个简单的多种类型标签混合使用，80/20原则，变态的地方不是存在项目的每个地方。

9.开发jsf的目的就是让你忘掉request的整个生命周期，当然不包括自定义组件开发者，对于普通开发者必要的了解是有助于开发，而不是必须的。所以我认为项目要使用jsf一定需要一个或几个横切式的开发者
10.javascript的需求最好别和jsf放在一起，除非已经进行了合理javascript组件封装，ajax的使用就是一把双刃剑，得自己掌握了。

11.任何项目的深度集成都会存在复杂的技术问题，和jsf这种技术没有关系，恰恰jsf的灵活插接设计很适合集成的需要，作为开发者要多多了解体系结构了。

12.使用jboss的测试解决方案，可以提供更优良的测试解决方案，但是seam和ejb3需要考虑使用，反过来表现层的单元测试在基于请求式框架中一向都比较难以实现，大部分展现层测试都是跑在容器内进行的，jsf解耦容器对象，为单元测试提供了更好的机制，目前除了jboss的jsfunit，还不知道有没有更好的实现。

13.项目中的困难往往是项目的领导者本身不熟悉jsf的开发模式所带来的，需要不断总结。

14.当你以后的项目都是使用jsf作为基础建设，你的思考不会总是停留在一个项目的成败，很多事情你还没有经历过，不要妄自评断。

个人感觉不是很喜欢组件这种东西，因为每一个组件封装了太多自身未知的东西，我没用过JSP不知道和.NET的DATAGRID这类的组件是否有雷同的地方。如果本身对JSP的常用组件都比较了解的话当时喜欢用，必定我知道它的底细么。感觉如果想用一个东西还是先熟悉它比较好，以降低项目的风险。所以如果让我用JSF可能学习的周期比较长。

您的意思主要是横彻功能组件实现服务于 多个项目吧，

注重自己核心技术的开发， 甚至自己业物型架构的开发。

如果是技术型公司，可以有效率保障自己技术核心竞争力而不被大公司所牵制。

先学习了。

JSF，两年前用过，它的MVC还是不错的，反正那时候用的比struts舒服。但是它的组件是在是太恐怖了，开发维护成本很高。用现成的却没有完全合适的，那时候apache的MyFaces项目有好几个UI的实现，各具特色，要是能整合一下也许会好的多。

说一点我的想法,就如同WINDOWS下的控件,其实开发一个难度也是相当大的,于是,就有了专业开发控件的公司,系统集成者,拿来用就行了.分工合作.

看看tapestry，wicket的组件开发吧。 一个html加上一个java class就是一个compoent。that's all.

JSF根本就不优雅，效率很低

太多争论没用
看看组里技术成熟度 定制 开发框架，这样更有效率

很多人开发jsf组件的目的都是想让自己的页面开起来更简洁，更美观。这是一种错误的想法，我并不是反对这种做法，其实这是每个开发者的重要目标，但是如果此仅仅作为jsf自定义组件开发的目的，那么你会需要开发大量的封装组件，对于jsf组件的高复杂性会让你觉得进入痛苦与黑暗。

jsf组件体系是相当的优秀，进入规范的组件有着明确的族系。那么也就是说你要是开发组件就一定要清楚自己属于哪一族类的，有没有角色位置都相同的组件，如果有那么是扩展，增强，还是重新构建，所以组件的开发是很核心的技术，会对你的技术积累有深远的影响。

jsf组件的体系中，很多web标记的渲染都是在组件中进行的，这样从规范来看是图省事，对于组件开发者来说就增加了组件继承式开发的负担，需要大量的阅读。所以这一是对自定义组件开发者有更高的要求，二也是要求组件的实践化道路上有着更好的组件渲染机制和方式。

其实你最后一句话说的很好，其实不仅仅适用用技术型公司，也适用拥有大型项目，或者考虑长远发展的公司。我的实践告诉我，当今流行的很多轻量级框架虽然带来了很强的短线利益，但是在应用集成，技术积累方面大多都是捉襟见肘，一无是处，固执的不肯放下观念，只是一种生产力的倒退，却还在意淫。（这不是说你，是当前流行的现象）