不使用JSF的原因[关闭]

64

我是StackExchange的新手，但我认为您可以为我提供帮助。

我们正在创建一个新的Java Enterprise应用程序，以替换旧版JSP解决方案。由于许多更改，UI和业务逻辑的各个部分将被完全重新考虑和重新实现。

我们首先想到的是JSF，因为它是Java EE中的标准。起初，我印象深刻。但是现在，我正在尝试实现一个功能原型，并且对使用它确实有一些严重的担忧。

首先，它创建了我见过的最糟糕，最混乱的无效伪HTML / CSS / JS混合。它违反了我在网络开发中学到的每一个规则。此外，它把所有东西紧密结合在一起：布局，设计，逻辑和与服务器的通信。我看不到如何舒适地扩展此输出，无论是使用CSS样式，添加UI糖果（例如可配置的热键，拖放小部件）还是其他方法。

其次，它太复杂了。它的复杂性非常出色。如果您问我，这是对基本Web技术的拙劣抽象，最终变得残废无用。我有什么好处？没有，如果您考虑的话。数百个组件？我看到了数以万计的HTML / CSS片段，数万个JavaScript片段以及成千上万个jQuery插件。它解决了很多问题-如果不使用JSF，就不会有。或完全是前控制器模式。

最后，我认为我们将不得不在两年之内重新开始。我看不到如何实现所有第一个GUI模型（此外；我们的团队中没有JSF专家）。也许我们可以以某种方式将其破解。然后会有更多。我确信我们可以破解我们的黑客。但是在某些时候，我们会陷入困境。由于服务层之上的所有内容都由JSF控制。我们将不得不重新开始。

我的建议是使用JAX-RS实现REST api。然后用客户端MVC创建一个HTML5 / Javascript客户端。（或MVC的某种风格。）顺便说一句；无论如何，我们都将需要REST api，因为我们也在开发部分Android前端。

我怀疑JSF是当今最好的解决方案。随着互联网的发展，我真的不明白为什么要使用这种“耙子”。

现在，优点/缺点是什么？我如何强调我不使用JSF的观点？在我的建议下使用JSF有什么优点？

— 布鲁诺·谢珀
source

24

这是来自新用户的精心编写的问题。不赞成投票时请考虑发表评论。

— ThiefMaster

2

由于您正在重写所有内容，因此我不仅会考虑不使用JSF，而且会考虑完全不使用Java。现代脚本语言（即非 PHP或Perl）非常不错，并且对开发人员友好。

— ThiefMaster

11

我没有投票，但这不是一个问题，这是一个大问题。Vain下定了决心讨厌JSF，现在他出于更多原因要求不使用JSF？

— Michael Borgwardt 2012年

4

如果您的应用程序要使用多种服务而变得庞大（复杂和/或可伸缩）和/或分布式，则Java是最佳选择。如果您的应用程序不属于此类（不是那么复杂并且不需要可伸缩），那么Python（Django）或Ruby（Rails）是更好的选择。JSF的复杂性具有其附带功能的优势；作为替代方案，如果必须使用Java，则应该看看其他Web框架，例如Spring MVC或Struts 2。

— m3th0dman 2012年

14

这是一个寻找备份的麻烦，而不是一个问题。

26

至少有一个很好的理由考虑使用JSF。

它是Java EE堆栈的标准部分，因此将在非常长的时间内在所有Java EE容器中可用并正常工作。如果您严格遵守Java EE规范，也无需维护。

如果您对此感到担忧，那么您应该考虑一下。大多数软件的寿命超出了设计人员的预期，特别是在编写时考虑到这一点。

4

对此我不确定。对于J2EE，“标准”和“工作”一词并不是一成不变的，特别是当我们谈论一个将被/应该被支持很多年的系统时，包括对所使用的j2ee版本的更改。

— magallanes 2013年

7

根据我对JSF的（有限）经验，该论点实际上不成立。我已经看到应用程序卡在一个版本的JSF中，并且没有向新版本迁移的明智方法。当然，应用服务器仍会执行它，但这就是如果您没有大量金钱可以花掉过多的支持合同而获得的所有支持。

— 延斯·肖德

@JensSchauder我的经验只是可以编写可移植的应用程序，迁移和升级其jsf版本。这涉及到了解规范并对其进行编码，而不是对其实现进行编码。它确实有效，因为为JPA编码而不是Hibernate起作用。已经这样做了多年。

— ymajoros

14

现在，优点/缺点是什么？我如何强调我不使用JSF的观点？在我的建议下使用JSF有什么优点？

您似乎已经对缺点有所顾忌，我必须同意其中的一些缺点（布局和逻辑不够充分，结果HTML常常很残酷），但对其他缺点（如果您使用我非常建议您使用Facelets，然后输出肯定是有效的）。

所以这是一些优点：

有一些非常强大的组件库，例如PrimceFaces或RichFaces，它们提供了许多现成的功能。如果它们满足您的要求，它们可以为您节省很多工作（如果您有不可协商的要求，则不能那么多）。
复合组件提供了一种非常干净的方式来模块化您的页面
JSF与Java EE的其余部分很好地集成
通过组件重新渲染的AJAX确实非常方便

但是，当然，这些优势都不是那么大，以至于您应该将JSF应用于您的团队已有经验的其他框架。

— 迈克尔·伯格沃特（Michael Borgwardt）
source

1

不是ID，而是无效的属性。在标签视图中就像“角色”和“ aria展开”一样。你知道如何解决这个问题吗？

— 布鲁诺·谢珀

1

@Vain：不，似乎是一个不同的问题，也许是因为我没有使用过或者是新的组件。通过指定备用渲染器（理想情况下，它会覆盖默认渲染器的一个或两个方法）来更改JSF组件的HTML输出是可能的，但是当然这不是您仅需获取有效标记所要做的事情。

— Michael Borgwardt

1

残酷的HTML归功于所使用的实现。据我了解，参考JSF实现的调试模式在这方面特别糟糕。您知道更好的设置来产生更好的HTML吗？

1

@ThorbjørnRavn Andersen是的，无效HTML的问题实际上是PrimeFaces的问题。我们使用它是因为它基于jQuery-UI。您有什么建议？我应该使用其他图书馆吗？我真的很喜欢有效的HTML。对我来说，这只是必须的。

— 布鲁诺·谢珀

1

在这里重温我的第一个问题，我想分享一些有关您的专业人士的经验：我们正在与JSF合作，而有了这一经验，我们将不再选择它。几乎所有东西都可以按预期工作并且开箱即用。是的，有强大的图书馆。但是我们最终自己完成了所有组件，因为它们无法按我们需要的那样工作。滚动时我们有了自己的带有延迟加载功能的“ DataTable”，速度之快令人惊叹。复合组件不适用于我们，我无法告诉您原因，我想它们是越野车。实际上，AJAX重新呈现对于客户端JS来说是很痛苦的。

— 布鲁诺·谢珀

9

JSF是Java的适当的有状态Web框架，这是一个标准，这意味着许多主要供应商（包括FOSS的供应商）均已对其提供现成的支持。它具有强大的第三方库支持（PrimeFaces，IceFaces等）。但是，由于它的有状态性（以及其他一些原因），它从根本上确实“破坏了网络”。参见Matt Raible对基于JVM的Web框架的比较，JSF通常接近最后。

使用JSF 2.2进行编辑-您可以开始争辩说它不会像以前那样破坏网络。实际上，它与HTML5的集成并不十分糟糕:-)。

— 马丁·弗伯格（Martijn Verburg）
source

1

确实，它“破坏了网络”。感谢Matt Raible的比较，我不知道这一点。

— 布鲁诺·谢珀

3

注意，JSF不一定是有状态的。我经常同意，但是对基于无状态GET的请求有很好的支持，如果您不使用表单，那么根本就没有状态。

— Arjan Tijms

公平点Arjan，我想我已经看到了许多有状态的用法。

— 马丁·韦尔伯格

链接到Raible的演示文稿：slideshare.net/mraible/…–

— zaidaus

6

我们有一个遗留的JSP / Struts 1.0应用程序。我们跳过了Struts 2，JSF以及自Struts 1以来发生的所有其他事情，并跳入了Spring 3.0。它为我们的愿望清单提供了支持（并且是一个活跃的社区）-Eclipse IDE，MVC和REST。另外，我们放弃了老式的Javascript / ajax开发jquery。

YMMV，但是Spring对我们来说是一个平稳的迁移。

— q
source