我们正在重新评估我们对 JSF 的使用（在我加入项目之前引入）与其他 Web 框架（如 Spring MVC）的可能使用。
在我看来，与使用 Spring MVC（我熟悉）相比，使用 JSF（从未开发过）构建页面的开发时间似乎需要很长时间。
我了解 JSF 是一个基于“组件”的框架，其理想的是构建或利用可重用组件。但到目前为止，情况并非如此。大多数（如果不是全部）页面都需要新组件。我估计页面开发需要几周的时间，我认为使用基于“Action”的框架可以在几天内完成。
想知道我是不是在这里离开了基地，或者所在的团队不是正确的团队，或者没有与 JSF 合作的正确技能。
我们的分析工具也遇到了问题，用户为页面添加书签和耗尽应用程序服务器堆 - 大量出现内存不足异常。
我们正在构建一个在 WebSphere 6.1 上运行的电子商务/拍卖网站。我们使用 Spring 和 Hibernate。
【问题讨论】：
标签： jsf
我们发现 JSF 的缺点：
我们已经迁移到 Groovy/Grails。 “默认”约定很容易理解，并且在必要时很容易绕过。约定也适用于修改框架（不更改多 xml/代码文件）。我根本不需要手动修改 XML 文件。它更易于使用，并且足够灵活，可以满足我们的需求。
Grails 结合了 Spring WebFlow 和 Hibernate，只是你不必修改 XML； Grails 编码约定在编译/运行时进行转换。
【讨论】：
我也是 Spring MVC 的忠实粉丝——尤其是与 Spring Webflow 结合使用时，这真是太棒了。现在 Webflow 可以与其他 Web 框架一起使用，但它最自然地适合 Spring MVC。
就我而言，我从 Struts (1) 转到 Spring MVC。我们为使用 Struts 建立了很多基础设施。在 Spring MVC 中编写新页面时，我低估了一件事情，那就是我们将花费多少时间来彻底改造该基础设施。我说的是验证、通用逻辑等等。
现在我对 JSF 知之甚少。听起来您遇到了这个问题（就像使用任何 Web 框架一样）。该过程仍在继续的事实可能是一个真正的问题。你不能忽视这样一个事实，你也会拥有它和其他东西。
我发现 Spring MVC 和 Webflow 是最好的，一旦你有一些围绕验证和表单逻辑的基础设施。例如，我们的系统中有很多这样的过程：
这听起来可能令人费解，但它出现了很多。 Spring MVC 真正闪耀的地方在于，对于这种场景，您可以创建一个自定义控制器，然后实际实现就变成了插入正确视图和支持 bean 的问题。
不要低估开发和测试所需基础架构的成本。
要考虑的另一件事是团队经验：如果没有其他人有 Spring MVC 经验，那么就会出现一些问题。
所以要非常小心，不要仅仅因为它会让你个人更舒服而改变。
【讨论】：