JSF 和 Spring 性能与差的 JSP 性能答案

【问题标题】：JSF and Spring performance vs poor JSP performanceJSF 和 Spring 性能与差的 JSP 性能
【发布时间】：2009-05-04 11:10:19
【问题描述】：

我看到我的同事开发了一些 JSF 项目，这些项目在我看来非常缓慢。有没有人有同样的看法？

我目前正在将 jsp+jstl 和 jQuery 用于“富”客户端。

我想知道现代框架（jsf、wicket、tapestry..）与旧的普通 jsp 相比有哪些优点和缺点。

如果使用所有这些技术的人都能回答，那就太好了。

对我来说，最令人兴奋的特性让你离开 jsp 并使用“大规模”框架也很有趣（我的意思是，例如 Spring 中的 AOP 或其他任何你能注意到的东西）。

感谢所有cmets。

【问题讨论】：

标签： java performance jsp jsf comparison

【解决方案1】：

我使用过 CGI、PHP、JSP、Struts、Spring MVC (1.2)、Bea Workshop、JSF、JBoss Seam、Spring MVC (2.5) 和 Wicket（按此顺序）。我注意到我所研究的每项新技术的生产力和质量都有所提高。它只是工作得更好，它感觉更好。我更喜欢 Wicket（带有弹簧、石英等）的所有其他。老实说，我看到了光明，我不想回到更黑暗——或更光明的一面；）——一面。

关于 Wicket 有很多话要说。

默认提供对话支持（或启用选项卡），您不必再担心“在新选项卡中打开”和“返回”按钮问题。
它是基于组件的，因此您可以重用代码 ala swing。
利用了许多标准 Java，例如类型安全奇迹。
支持 URL 加密等高级安全功能。
默认情况下可集群应用程序。
而且，最重要的是，它使用起来有趣。

JSP 和 JSF 有很多需要改进的地方。

最困扰我的一件事是“EL”的废话，因为我相信它破坏了漂亮的 java 类型的安全性和强度。
两者都需要工具支持以提高生产力。
您需要在它们之上的另一个框架才能真正解决问题（如 seam 框架所示，这使得 JSF 可用）。
错误处理非常棘手，异常没有直接帮助。
很难在两个框架上制作可重用的组件，并且不支持适当的关注点分离模型。
...而且，最重要的是，还有一连串的小痛，比如this，或this。

【讨论】：

是的，检票口很好！您还应该尝试 Grails（使用 GORM 作为非常强大的 ORM 层）。它类似于 ruby on rails。

【解决方案2】：

我非常喜欢使用 JSP 2.0 作为模板技术——也就是说，我使用 Spring MVC 来访问我的域对象并为某个视图准备我需要的所有数据，并将其留给 JSP 来呈现它。 JSP 2.0 因为我喜欢使用标签文件进行模板合成，这允许我在需要其他合成框架的地方使用简单的 JSP 2.0。

我有意避免在 JSP 中基本上是编程的所有内容。没有数据访问，没有 SQL，没有小脚本，没有方法，什么都没有。只是简单地展示预先存在的、控制器提供的数据，可能还有一些简单的案例和集合的迭代。

【讨论】：

很高兴听到这个消息。我使用 JSP 的方式与 Spring MVC 相同，而且非常好且速度快。

【解决方案3】：

许多优点。我可以列举我使用过的 JSF 优势在我的上一个项目中。

导航的集中位置（如在 struts 中）
日期选择器、自动完成、分页等组件。
您为布局提供了渲染，这有助于很多布局逻辑。
瓷砖的可用性，例如在 struts 中。

JSP 没有明确区分业务逻辑和布局。

无论如何，尽管所有这些优势，如果您是一名 Java 程序员，我建议您看看 Grails，这会更舒服。

【讨论】：

现在的名字只是“Grails”； Ruby on Rails 人员要求他们更改它。
很高兴知道。感谢您的评论。你得到了我的意见。
Grails 的两个替代方案是： 1. Lift (liftweb.net)。它在 JVM 上运行，但您必须学习 Scala（尽管这是一种很好的学习语言 :-)）。 2. JRuby on Rails，即运行在 JVM 上的 Rails (wiki.jruby.org/wiki/JRuby_on_Rails)。同样，虽然 JRuby 在 JVM 上运行，但您必须学习 Ruby 才能使用它。

【解决方案4】：

JSP 非常原始，您基本上没有小部件并且必须自己构建所有内容。虽然 JSF 的改进并不是最好的 java web 框架——还有很多其他的框架可以让你获得更令人印象深刻的结果——例如 GWT。

【讨论】：

这可能有偏见，但对我来说，GWT (code.google.com/webtoolkit) 更像是一个网络前端框架，而不是一个真正的网络框架。
我也认为 JSP 没有用，尤其是它在 Java EE 中的存在。它应该只是一个可选库。但似乎大多数人喜欢混合内容和代码（这是一种反模式）。
@Javier 最后是关于用户的最终体验，两者都交付给浏览器。用户并不关心它是如何到达那里的，只要它可以工作并让他们开心。

【解决方案5】：

Spring MVC 的好处：

该框架巧妙地鼓励您编写设计更好的代码：通过使用依赖注入，并将您的应用程序设计拆分为域（模型）对象、控制器、服务类、DAO 等。
作为第一个要点的副作用，您的代码最终会非常且易于进行单元测试。

【讨论】：