JSF vs Stripes，哪个最好？ [关闭]答案

【问题标题】：JSF vs Stripes, which is best? [closed]JSF vs Stripes，哪个最好？ [关闭]
【发布时间】：2010-04-15 14:02:20
【问题描述】：

哪个最好，或者换句话说，哪个最容易使用？条纹或 JSF。

虽然我没有在愤怒中同时使用这两种方法，但我需要衡量对于启动新项目和转换现有 Struts 项目来说，最好的选择是什么。

我担心 JSF 不会像我想要的那样渲染，但是其他人的经验是什么？似乎 Stripes 更直接，我的假设是否正确？

【问题讨论】：

【解决方案1】：

哪个最好，或者换句话说，哪个最容易使用？条纹或 JSF。

哪个是最好的？好吧，Stripes 和 JSF 是不同的。前者是基于动作的框架（如 Struts），而后者是基于组件的（如 Wicket）。因此，答案将取决于您对基于动作的流程与基于组件的层次结构的经验和知识，两者都有其优点和缺点。哪个最容易？条纹，毫无疑问。

我喜欢 Stripes 的原因：

简单易行，即学习曲线低。
我喜欢它的约定优于配置的方法。
它很轻。
文档齐全（由于其简单性，您不需要大量文档）。
它有一个小型但反应性社区（您将在mailing lists 上获得答案）。

如果您对两者都不熟悉，我会选择 Stripes。如果你想学习基于组件的框架，我认为从 Wicket 开始会更容易（另请参阅 Gavin King 在How to start learning Java EE 6 中所说的）。

【讨论】：

+1 我非常同意所有这些观点（尤其是文档——我对它们的出色程度感到惊讶，很多开源工具的文档还有很多不足之处，条纹食谱太棒了！）（尽管我在 Stripes 社区的体验没那么快！）
@James 好点，对速度的感知在某种程度上是主观的，我已经更新了我的答案。
条纹简直太棒了！它是最优雅的 MVC 框架，不需要复杂的 XML 配置。它没有陡峭的学习曲线，提供 SEO 友好的链接，而且速度极快！
@Kdeveloper 和 stripes 不需要你构建每一个小部件，这就是所有的 javascript、css 等。如果你只想要无聊的纯 HTML 元素，那么它就可以了。
@mp：Stripes 是一个轻量级框架，因为它可以完全控制生成的 HTML，它可以与任何 Javascript 组件框架（Yui、JQuery UI 等）结合使用。这使得 Stripes 特别适合构建需要完全控制其 HTML 的面向消费者的网站。

【解决方案2】：

JSF 没有良好的媒体和坏名声是有道理的（已故的 Sun Microsystems 又错过了一次机会）。但是，自从提出问题以来，发生了很多变化——新的 JSF 2.0 版本发布了。

那么，JSF 1.X 出了什么问题，与 Stripes、Spring MVC 或 Wicket、Play、Click 等相比，是什么让它如此恼人？

仅支持 POST 请求，这会导致性能问题（GET 请求可以被有效缓存）、难以实现可收藏的 URL 等等
JSF 1.X 基于 JSP 页面，不适合处理更复杂的 JSF 页面生命周期
创建组件既困难又麻烦。
导航规则的定义远非灵活且非常冗长
强制 XML 配置
没有干净的资源管理方法

好消息是新的 JSF 版本解决了所有这些缺点。

GET 和 POST 请求同样得到很好的支持。
配置可以在注释的帮助下完成（我们可以坚持使用 XML 更好的解决方案），简化导航规则定义，我们甚至可以使用约定优于配置的方法。
组件创建很容易。
有新的非常有用的组件范围：视图范围和闪存范围（类似于 Ruby on Rails 中已知的范围），使用户能够轻松处理更复杂的流程。
有标准的资源管理方法和更好的错误处理工具
我们可以定义项目阶段，以便在各种环境（测试、生产等）中更轻松地处理项目
基于 XHTML 的 Facelets 取代了 JSP，成为更好的视图定义替代方案
内置 AJAX 请求支持
JSF 是 Java EE 标准的一部分，这意味着如果无聊的开发人员决定转向下一个闪亮和更时尚的框架，它们不会在一夜之间消失。

还有最后一点，JSF 2.X 的巨大优势：设计精良、外观精美且性能良好的即用型组件（RichFaces、PrimeFaces、ICEFaces）。这些库提供了数百个通常用于 WWW 页面的组件，无需编写任何 JavaScript 或 CSS 即可使用。这极大地提高了生产力。

不过，与 Stripes 等基于动作的框架相比，JSF 可能存在性能问题，后者更接近 HTTP 请求，无需构建组件模型（使用更多内存、更多网络带宽）。

但是对于不需要非常高性能的应用程序，JSF 2.0 是一个非常好的和合理的选择。学习曲线不再像以前那样陡峭，再加上重用现有组件的能力使其真正具有吸引力。从这个角度来看，条纹并没有那么吸引人。

因此，例如，对于 2000 名员工使用的 Intranet 公司应用程序，JSF 2.0 将是不错的选择。

【讨论】：

感谢 Piotr，自从提出这个问题以来，我已经调动了工作，并且深入了解了 JSF 1.2 应用程序。出于您所说的原因，JSF 2.0 即将推出。

【解决方案3】：

最好的网络框架？就像通常这个问题会导致“视情况而定”的答案一样。

另一个问题：“什么是最容易使用的框架”。更容易回答，即条纹。 JSF 有一个臭名昭著的陡峭学习曲线。另一方面，Stripes 易于设置且易于学习。

Stripes 框架类似于 Struts，但更好。对于example，它使用注释而不是 XML 配置文件。就像 Struts 框架一样，它是一个基于动作的框架，只是更优雅。这意味着它紧跟 HTTP 事件处理的无状态特性。如果您希望在生成页面时获得高性能和最大的灵活性，这是很好的选择。

像 JSF 这样的框架不是基于动作的框架，而是基于组件的框架。这意味着它在 HTTP 和您的应用程序之间移动了一层抽象。这一层使编写 JSF 应用程序成为可能，就像在编写 Swing 应用程序一样。因此 JSF 基本上处理了组件模型和无状态 HTTP 生命周期之间的范式不匹配。然而，这一抽象层会消耗一些性能；它还会让您对生成的 HTML 的控制程度有所降低。

【讨论】：

【解决方案4】：

jsf 使用得更多，所以如果发生任何奇怪的事情，你应该得到更好的支持。这足以让我使用它。

【讨论】：

不同意 - JSF 中会发生更多“奇怪”的事情，因为它要复杂得多。这足以让我不使用它。
不正确。 JSF 遇到了许多问题，而这种所谓的“更好的支持”并没有解决这些问题。

【解决方案5】：

我会使用 JSF。它的使用范围更广，iceFaces 是一个非常方便的基于 JSF 的应用程序包。

【讨论】：

为什么要投反对票？请解释一下？

【解决方案6】：

JSF 是 Java EE 6+ 的一部分。这意味着它将在很长一段时间内可用和维护，这对我们很重要。

还可能会出现不同的实现，这使您可以为给定目的选择最佳的实现。

【讨论】：

【解决方案7】：

Seam 是用于开发 JSF 应用程序的不错的应用程序堆栈，但对 Stipes 不确定。

转化次数
很好的 ajax 支持
丰富的组件集
基于 XML 配置的注释

我不喜欢 JSF 的一点是学习曲线太高，特别是如果您是 JSF 的新手。

【讨论】：

带有 facelets 的 JSF 2 比 JSF 1 好得多。

【解决方案8】：

Struts 之类的 Stripe 对您的应用程序并没有多大帮助。除了一些基本的路由和表单填充以及执行操作之外，它基本上什么都不做。上次我检查了大多数（所有）条纹标签基本上是等效 html 标签的立面，几乎没有或没有额外内容。也就是说，JSF 确实提供了更多，但如果您想要一种真正的技术，而不是停留在 2000 年，请考虑 GWT。

【讨论】：