JSF vs其他web框架的使用

Question

我们正在重新评估我们在使用JSF（引入到项目之前带入）与其他Web框架（如Spring MVC）的可能用法之间的关系。

从我的观点来看，与使用Spring MVC（我熟悉的）相比，开发页面的开发时间似乎需要很长时间才能使用JSF（从未开发过）。

我知道JSF是一个基于“组件”的框架，具有构建或使用可重用组件的理想框架。但到目前为止，情况并非如此。大多数（如果不是全部）页面都需要新的组件。我正在估计几周的页面开发，我觉得可以在几天内使用基于“Action”的框架来完成。

想知道我是否在这里休息，或者现场的团队可能不是正确的团队，或者拥有与JSF一起工作的正确技能。

我们还遇到了我们的分析工具问题，即用户为页面添加书签并吹出应用程序服务器堆 - 很多内存异常。

我们正在构建运行在WebSphere 6.1上的电子商务/拍卖网站。我们使用Spring和Hibernate。

Answer 1

我也是Spring MVC的忠实粉丝 - 尤其是当与Spring Webflow结合使用时，这非常棒。现在，Webflow可以与其他Web框架一起使用，但最适合Spring MVC。

就我而言，我从Struts（1）转到了Spring MVC。我们有很多使用Struts的基础设施。在Spring MVC中编写新页面时，我低估了一件事情，那就是我们花了多少时间在本质上重新创建该基础结构。我正在谈论验证，共同逻辑等等。

现在我对JSF一无所知。这听起来像你有这个问题（就像你使用任何Web框架一样）。这一进程仍在进行的事实可能是一个真正的问题。你不能忽视这样一个事实，即你会用别的东西来获得它。

我发现Spring MVC和Webflow是最好的，一旦你有一些基础设施围绕验证和形式逻辑。例如，我们的系统上有很多这样的过程：

1. 用户地点的顺序;
2. 服务器验证参数并拒绝订单（返回（1））或接受它;
3. 已验证的订单将返回以显示给确认他们要下订单或取消订单的用户;
4. 如果他们取消它，显示一个页面说它已被取消;
5. 如果他们批准它，再次验证订单;
6. 如果验证失败返回（1）;
7. 否则放置订单并将结果显示给用户。

这听起来可能令人费解，但它出现了很多。在这种场景下，Spring MVC真正发挥了作用，你可以创建一个自定义控制器，然后实际的实现就成为插入正确视图和支持bean的问题。

不要低估开发和测试所需基础架构的成本。

其他的事情要考虑的是团队的经验：如果没有人其他人有Spring MVC的经验，那么这是怎么回事提出的一些问题。

所以要非常小心，不要因为它会让你更舒适而改变。 JSF的

Answer 2

缺点，我们发现：

• “标准”的5相路径是非常简单和灵活。
• 从正常变方法是复杂的和非直观
• 您根本不能没有的Facelets和Rich/ICEFaces的使用JSF ..至少，其它修改/插件是有帮助的（SEAM等）
• 封装功能以使事情“更简单”是可以的......在情况需要的时候，不可能在那里搞砸。试图设计一个客户端反应页面时
• 服务器端存储组件树是非常不方便的。

我们已经搬到了Groovy/Grails这里。 “默认”约定很容易理解，并且在必要时很容易绕过。约定也适用于修改框架（不需要更改多个xml /代码文件）。我还没有必要手工修改XML文件。这与合作更容易，并且足够灵活以满足我们的需求。

Grails的集成访问Spring WebFlow和Hibernate，只有你没有修改XML; Grails编码约定在编译/运行时转换。