JSF的优雅 带来的项目成本

JSF架构的实现大多是开源。我不知您有没有这样的经历。当您引入一个开源架构后解决当前的某类问题，但以后的项目进展往往会由它引来更多的问题，由其JSF，如果今天觉得Facelets不错，把它加在项目里，明天客户要上AJAX，又不得不把Ajax4JSF加上。您的不可控的因素也增加，由过去的一个开源架构带来的风险现在扩展为两个。也许会用的很 HAPPY。但项目的二三期一上，马上会面监升级的技术风险。我到见过不少公司，做行业级项目，宁愿自己写行业级的架构，尽量归避开源带来的风险。（但有时候时间与成本的考量也不得不考虑开源）

你的项目所遇到的问题更多体现在了过程式分工的开发模式，我猜测可能每个开发组，每个开发人员都有一份切割过的要求和任务。那么对于简单，直接的框架最合适，及时大家都在重复的写代码，但是在一个级别上都很清楚运行机制和原理，即使有不熟的也无大碍，因为技术的普及性很好。所以你的项目还不适合使用jsf，毫不客气的说你的项目还依旧没有贯彻OO的设计思路，具体的讲来struts的action命令，spring的无状态外观正好符合了这种过程模式，jsf真的不适合你的项目，从失控的代码质量更能说明使用jsf并没有很好的解决这个问题，灵活的pojo机制反而带来了更混乱的对象交互，你们的设计者不去充电就得退休！
与其说是改变思维，不如说大部分的项目一直是都是打着OO的招牌做着过程式路线的生意，当真正遇到OO了就觉得像是遇到了异类！

一个产品，不可能是十全十美的。JSF也是一样，需要的是你善于使用它，而不是说是和所有的项目，正所也善驾于物也。适合的才是最好的。用jsf那就充分发挥它的优势，以矛攻盾无非是两败俱伤。
我们不能否认，jsf让页面更加灵活，更加绚丽，以前只有在cs中看到的现在jsf可以做到了，这就是现在说的富客户端。现在很火热的ajax，我想jsf跟ajax结合的是相当好的了。

想问问正在用JSF做项目的各位：如果你们有决定权，还选择JSF么？

个人觉得这个技术成本有点高吧。