Java Server Faces 2.0的主要缺点是什么？

昨天我看到了一个关于Java Server Faces 2.0的演示，虽然我现在是一个快乐的ASP.NET MVC / jQuery开发人员，但看起来确实令人印象深刻。 我最喜欢JSF的是大量支持AJAX的UI组件，这些组件似乎使开发速度比ASP.NET MVC快得多，尤其是在AJAX网站上。 集成testing看起来也非常好。

由于演示文稿只强调了JSF的优势，所以我想听听另外一个方面的内容。

所以我的问题是：

• Java Server Faces 2.0的主要缺点是什么？
• 什么可能使JSF开发人员考虑使用ASP.NET MVC而不是JSF？

Answer 1

JSF 2.0的缺点？ 老实说，除了相对陡峭的学习曲线，当你没有关于基本Web开发 （HTML / CSS / JS，服务器端与客户端等）和基本的Java Servlet API （请求/响应/会话） ，转发/redirect等），不会出现严重的缺点。 JSF在当前的版本中仍然需要摆脱它在早期获得的负面形象，在这个过程中存在几个严重的缺点。

JSF 1.0（2004年3月）

这是最初的版本。 在你不想知道的核心和性能方面，它都有一些bug。 你的web应用程序并不总是按照你直觉的预期工作。 你作为开发人员会跑得很难哭。

JSF 1.1（2004年5月）

这是错误修正版本。 performance还没有太大的改善。 还有一个主要的缺点：无法完美地在JSF页面中embeddedHTML。 所有普通的香草HTML在JSF组件树之前被呈现。 您需要将所有普通香草包装在<f:verbatim>标记中，以便它们包含在JSF组件树中。 虽然这是按照规范，这已经收到了很多批评。 另请参阅ao JSF / Facelets：为什么将JSF / Facelets与HTML标签混合并不是一个好主意？

JSF 1.2（2006年5月）

这是由Ryan Lubke领导的新的JSF开发团队的第一个版本。 新队伍做了很多很棒的工作。 规格也有变化。 主要的改变是视图处理的改进。 这不仅是完全脱离JSP的JSF，所以人们可以使用与JSP不同的视图技术，但是它也允许开发人员在JSF页面中插入普通的纯粹HTML，而不会与<f:verbatim>标签混淆。 新团队的另一个重点是提高绩效。 在Sun JSF参考实现1.2（从2008年的1.2_08版本开始，代号为Mojarra）的生命周期中，几乎每个版本都会在常规（次要）错误修正旁边进行（主要）性能改进。

JSF 1.x（包括1.2）的唯一严重缺点是在请求和会话范围（即所谓的对话范围）之间没有范围。 这就迫使开发人员无论何时想要在后续请求中保留初始模型数据，以便成功处理更多的validation，转换，模型更改和动作调用，都会隐藏隐藏的input元素，不必要的DB查询和/或滥用会话范围复杂的web应用程序。 在MyFaces Tomahawk <t:saveState>组件， JBoss Seam对话范围和MyFaces Orchestra对话框架等后续请求中保留必要数据的第三方库，可以缓解这种痛苦。

HTML / CSS纯粹主义者的另一个缺点是JSF使用冒号:作为ID分隔符来确保生成的HTML输出中HTML元素id唯一性，特别是当一个组件在视图中多次重复使用时（模板化，迭代组件，等等）。 由于这是CSS标识符中的非法字符，因此您需要使用\来转义CSSselect器中的冒号，导致类似#formId\:fieldId {}甚至#formId\3A fieldId {}丑陋和奇怪的select器。 。 另请参见如何在CSSselect器中使用带有冒号“：”的JSF生成的HTML元素ID？ 但是，如果您不是纯粹主义者，请阅读默认情况下，JSF生成不可用的ID，它与Web标准的CSS部分不兼容 。

另外，JSF 1.x没有提供开箱即用的Ajax工具。 这不是一个技术上的缺点，但是由于在这个时期的Web 2.0炒作，它成为一个function缺陷。 Exadel很早就推出了Ajax4jsf，这个年代被彻底开发出来，成为了JBoss RichFaces组件库的核心部分。 另外一个组件库也内置了Ajax的function，众所周知的是ICEfaces 。

大约在JSF 1.2生命周期的一半，引入了一个新的基于XML的视图技术： Facelets 。 这在JSP上面提供了巨大的优势，特别是在模板方面。

JSF 2.0（2009年6月）

这是第二个主要版本，以Ajax作为stream行语。 有很多技术和function上的变化。 JSP被Facelets替代为默认的视图技术，Facelets被扩展为使用纯XML（所谓的复合组件 ）创build自定义组件的function。 另请参见为什么Facelets比JSF2.0更适合作为视图定义语言？

Ajaxfunction被引入了与Ajax4jsf有很多相似之处的<f:ajax>组件。 引入了注释和约定优先configuration增强function，尽可能多地faces-config.xml详细的faces-config.xml文件。 另外，默认的命名容器ID分隔字符:变得可configuration，所以HTML / CSS纯粹主义者可以松一口气。 您只需将其定义为web.xml中的名为javax.faces.SEPARATOR_CHAR init-param ，并确保您不在自己的客户端ID的任何位置使用该字符，例如- 。

最后但并非最不重要的一个新范围被引入， 视图范围。 它消除了前面所述的另一个主要的JSF 1.x缺点。 您只需声明bean @ViewScoped即可启用对话范围，而无需在后续（对话）请求中保留数据。 一个@ViewScoped bean只要您随后提交并同步或asynchronous（Ajax）导航到相同的视图（独立于打开的浏览器选项卡/窗口！），就会生活。 另请参见托pipeBean中的View和Request作用域之间的区别以及如何select正确的Bean作用域？

虽然实际上JSF 1.x的所有缺点都被消除了，但是JSF 2.0特定的错误可能会成为一个难题。 @ViewScoped在标签处理程序中由于部分状态保存的鸡蛋问题而失败 。 JSF 2.2修复了这个问题，并且在Mojarra 2.1.18中回溯了这个问题。 还不支持像HTML5 data-xxx一样传递自定义属性 。 这通过新的直通元素/属性function在JSF 2.2中得到了修复。 此外，JSF的实现Mojarra有自己的一套问题 。 相对来说，它们中的很多都与<ui:repeat>的有时是不直观的行为 ， 新的部分状态保存实现以及实施不佳的闪存范围有关 。 他们中的大多数都是在Mojarra 2.2.x版本中修复的。

围绕JSF 2.0时代， PrimeFaces是基于jQuery和jQuery UI而推出的。 它成为最受欢迎的JSF组件库。

JSF 2.2（2013年5月）

随着JSF 2.2的推出，HTML5被用作stream行语，即使这在技术上只是在所有较旧的JSF版本中都支持。 另请参阅JavaServer Faces 2.2和HTML5支持，为什么还要使用XHTML 。 最重要的新JSF 2.2function是支持自定义组件属性，因此打开了一个世界的可能性，如定制无表单选button组 。

除了实现特定的bug和一些“烦人的小事情”，比如无法在validation器/转换器中注入EJB（已经在JSF 2.3中修复）之外，JSF 2.2规范并没有真正的主要缺点。

基于组件的MVC与基于请求的MVC

有些人可能会认为JSF的主要缺点是对生成的HTML / CSS / JS的控制很less。 这不是JSF自己的，这是因为它是一个基于组件的 MVC框架，而不是基于请求（动作）的 MVC框架。 如果高度控制HTML / CSS / JS是您考虑MVC框架的主要要求，那么您应该已经不是在查看基于组件的MVC框架，而是在基于请求的MVC框架（如Spring MVC）上 。 你只需要考虑到你必须自己编写所有的HTML / CSS / JS样板文件。 请参阅请求MVC和组件MVC之间的区别 。

也可以看看：

• JSF，Servlet和JSP有什么区别？ （只是为了了解基础知识）
• 使用JSF开发无表格CSS布局 （关于JSF的另一个神话）
• JSF vs纯HTML / CSS / JS / jQuery （当JSF是错误的select）
• Web应用程序中的devise模式 （说明了MVC背后的意识形态）

Answer 2

在JSF工作了5年之后，我想我可以加2美分。

JSF的两个主要缺点：

1. 大的学习曲线。 JSF是复杂的，这是真的。
2. 其组件性质。 基于组件的框架试图隐藏networking的真实性质，这带来了大量的复杂和灾难（比如在近5年内不支持JSF中的GET）。
   恕我直言，隐藏HTTP请求/响应从开发人员是一个巨大的错误。 根据我的经验，每个基于组件的框架都会为Web开发添加抽象，而抽象会导致不必要的开销和更高的复杂性。

我想到的一些小缺点：

1. 默认情况下，对象的ID由其父母的ID组成，例如form1：button1。
2. 没有简单的方法来评论不正确的页面的片段。 标记<ui:remove>需要语法正确的内容，无论如何都是parsing的。
3. 低质量的第三方组件，例如在继续之前不检查isRendered()在processXxx()方法中。
4. 纳入LESS＆Sencha很难。
5. REST玩不好。
6. 用户体验devise师不那么容易，因为随时可用的组件有自己的CSS样式，需要被覆盖。

不要误解我的意思 作为一个组件框架JSF在版本2是非常好的，但它仍然是基于组件的，总是会…

请看看Tapestry，Wicket的低人气以及经验丰富的JSF开发人员的低热情（甚至更有意义）。 相比之下，看看Rails，Grails，Django，Play的成功！ 框架 – 它们都是基于行动的，不要试图隐藏程序员真正的请求/响应和networking的无状态性质 。

对我来说这是JSF的主要缺点。 恕我直言JSF可以适合某些types的应用程序（内联网，forms密集型），但是对于真实的Web应用程序，这不是一个好的方法。

希望能够帮助他/她select前台的人。

Answer 3

记住一些缺点：

1. JSF是一个基于组件的框架。 这具有与遵守组件模型有关的内在限制。
2. AFAIK JSF只支持POST，所以如果你想要一个GET的地方，你必须做一个普通的servlet / JSP。
3. 大多数组件试图对关系数据库和前端JavaScript等领域提供抽象，很多时候这些抽象是“泄漏”的，而且很难debugging。
4. 这些抽象可能是一个初级开发人员或不熟悉特定领域（例如前端JavaScript）的人的一个很好的起点，但是很难优化性能，因为涉及到多个层，大多数人使用它们对引擎盖下面发生的事情一无所知。
5. 通常与JSF一起使用的模板机制与webdevise者的工作方式无关。 JSF的WYSIWYG编辑器是原始的，无论如何，你的devise者会给你HTML / CSS，你将不得不花很多时间来转换。
6. 像ELexpression式这样的东西没有被静态检查，编译器和IDE在查找错误方面都做得不好，所以最终会出现在运行时必须捕获的错误。 对于像Ruby或者PHP这样的dynamictypes语言来说，这样做可能没问题，但是如果我必须承受Java生态系统的巨大膨胀，那么我需要为我的模板打字。

总结一下：用JSF保存的时间，从避免写JSP / servlet / bean样板代码，你将花费x10来使它扩展，并做你想做的事情。

Answer 4

对我来说，JSF 2.0最大的缺点是不仅JSF的学习曲线，而且你必须使用的组件库才能使它有用的工作。 考虑一下你所处理的规格和标准数量惊人，

• HTML中的各种化身。 不要假装你不需要知道它。
• HTTP – 当你不知道发生了什么，你必须打开Firebug，看看。 为此，你需要知道这一点。
• CSS – 喜欢与否。 真的不是那么糟糕，至less有一些很好的工具。
• XML – JSF可能是第一个使用名称空间的地方。
• Servlet规范。 迟早你会进入这个包中的调用方法。 除此之外，你必须知道你的Facelets如何变成XHTML或其他。
• JSP（主要是你知道为什么你不需要JSF）
• JSTL（同样，主要是为了应对遗留的框架）
• expression语言（EL）有各种forms。
• ECMAScript，JavaScript或其他任何你想称之为的东西。
• JSON – 即使不使用，也应该知道这一点。
• AJAX。 我会说JSF 2.0做了一个体面的工作来隐藏你，但你仍然需要知道发生了什么。
• DOM。 以及浏览器如何使用它。 请参阅ECMAScript。
• DOM事件 – 一个话题本身。
• Java持久性体系结构（JPA），即如果您希望您的应用程序具有任何后端数据库。
• Java本身。
• JSEE，而你在这。
• 上下文dependency injection规范（CDI）及其与JSF 2.0冲突的方式
• JQuery – 我希望看到你没有它相处。

现在，一旦你完成了这个工作，你就可以继续使用专有的规范，即组件库和提供程序库，

• PrimeFaces（我select的组件库）
• RichFaces的
• MyFaces的
• ICEFaces的
• EclipseLink（我的JPA提供程序）
• 过冬
• 焊接

别忘了容器！ 所有这些configuration文件：

• GlassFish（2,3等）
• JBoss的
• Tomcat的

所以 – 这是很容易吗？ 当然，只要你想做的是最简单的交互的最基本的网页，JSF 2.0是“容易的”。

简而言之，JSF 2.0是目前软件领域存在的最复杂和最麻烦的粘合技术。 我想不出任何我想用的东西。

Answer 5

“JSF将输出View-layer HTML和JavaScript，无需进入Controller代码就无法控制或更改。”

实际上，JSF为您提供了灵活性，您可以使用标准/第三方组件或创build您自己的组件，并完全控制渲染的内容。 这只是一个你需要用JSF 2.0创build自定义组件的xhtml。

Answer 6

1. 没有经验的开发人员通常会创build令人痛苦的应用程序，代码将会非常难以维护。 它看起来很简单，但如果你想编写好的程序，实际上需要一些投资。
2. 至less在一开始，你会经常“卡住”一些问题，并会花费更多的时间在互联网上阅读balusc的post，而不是真正的工作:)过了一段时间，它会越来越less，但它仍然可以是烦人的。
3. 当你发现问题不是由于你缺乏知识/错误，而是一个错误时，更令人讨厌。 莫哈拉是（是？）相当有问题，另一层组件增加了更多的问题。 Richfaces是有史以来最大的垃圾软件:)不知道它是如何在版本4上。我们Primefaces是更好的，但仍然会遇到缺陷或function缺乏，尤其是与更奇特的组件。 现在您需要为Primefaces更新付费。 所以我会说它的越野车，但它变得越来越好，特别是在2.2版后修正了一些规格问题。 框架越来越成熟，但还远远不够完美（也许myfaces更好？）。
4. 我不觉得它特别灵活。 通常情况下，如果你需要一些非常非常自定义的东西，而且没有这样的组件，那将会有点痛苦。 再次，我是从平均开发人员的angular度来谈谈 – 最后期限，快速阅读教程和search时，因为没有时间，因为没有时间来学习如何真正的工作:) stackoverflow通常一些组件似乎有“几乎”你所需要的，但不完全，有时你可能会花太多的时间来做它你想要的东西:)需要小心评估，如果它更好地创build自己的或酷刑现有的组件。 其实如果你正在创造一些非常独特的东西，我不会推荐JSF。

所以总之我的缺点是：复杂性，不是很顺利的开发进度，越野车，僵化。

当然也有好处，但这不是你问的。 无论如何，这是我的经验与框架其他人可能会有不同的意见，所以最好的方法是尝试一段时间，看看它是否适合你（只是更复杂的东西 – 不是天真的例子 – JSF真的闪耀那里:)恕我直言最好的用例JSF是商业应用程序，如客户关系pipe理等…

Answer 7

我们用JSF开发了一个样例项目（这是一个三周的研究，所以我们可能会失去一些东西！）

我们尝试使用核心jsf，如果需要组件，我们使用PrimeFaces。

该项目是一个导航的网站。 单击菜单时，应通过ajax加载每个页面。

该网站有两个用例：

1. 带有网格的页面。 网格通过ajax加载，应该支持sorting和分页
2. 三步向导页面。 每个页面都有客户端validation（用于简单validation）和服务器端Ajax基础validation（用于复杂validation）。 任何服务器exception（来自服务层）都应显示在向导的同一页面上，而无需导航到下一页。

我们发现：

1. 您需要使用omniFaces中的一些hack来修复JSF视图状态。 当通过ajax包含页面时，JSF状态将被破坏。 这似乎是JSF中的一个错误，可能会在下一个版本中修复（不在2.3版本中）。
2. JSFstream与ajax无法正常工作（或者我们不能使它工作！）我们尝试使用primeface向导组件，但是客户端validation似乎不被支持，并且意味着它不是标准的JSFstream标准。
3. 在使用jqGird等jQuery组件时，如果需要加载JSON结果，那么build议您使用纯的servlet，JSF将不会为您做任何事情。 所以如果你使用这些组件，你的devise将不适合JSF。
4. 当ajaxComplete完成ajax时，我们尝试做一些客户端脚本，我们发现PF 4已经实现了自己的ajax事件。 我们有一些jQuery组件，我们需要改变他们的代码。

如果将上面的示例更改为非Ajax项目（或者至lesslessajax项目），则不会面临上述许多问题。

我们将我们的研究总结为：

JSF在ajax基础网站上效果不佳。

当然，我们在JSF中发现了很多不错的function，可能对某些项目非常有用，所以请考虑您的项目需求。

请参考JSF技术文档来评论JSF的优势，在我看来，JSF的最大优势在于@BalusC的完整和巨大的支持;-)

Answer 8

我根本不是Java Server Faces专家。 但恕我直言，主要缺点是，它是服务器端。 我厌倦了学习和使用ASP.NET Web窗体，ASP.NET MVC，Java Server Faces，Struts，php框架和Ruby on Rails框架等服务器端Web表示层框架。 我告别了所有的人，我向Angularjs和TypeScript问好。 我的表示层在浏览器上运行。 我无所谓，如果它由运行PHP或ASP.NET的Windows IIS提供服务，或者由运行在Linux上的Apache Web服务器提供。 我只需要学习一个可以在任何地方工作的框架。

只是我的两分钱。

Answer 9

对我来说，JSF最大的缺点是对编程（dynamic）生成的页面的支持不足。
如果你想从Java代码dynamic地构build页面（创build页面组件模型）。 例如，如果您正在使用所见即所得的网页构造函数。 此用例的充分文档通常不可用。 有很多点你必须试验和发展是安静的慢。 许多事情不能如你所期望的那样工作。 但通常它可能会破解它。
好的是这不是JSF的哲学或架构问题。 这只是没有足够的阐述（据我所知）。

JSF 2带来了复合组件，它应该使组件开发变得容易，但是它们对dynamic（程序化）构build的支持却很差。 如果你克服了静态复杂的，几乎没有logging的dynamic复合组件构造过程，你会发现，如果你嵌套几个复合组件更深，他们停止工作，抛出一些例外。

但似乎JSF社区意识到了这个缺点。 正如你从这两个bug中看到的那样，他们正在对此进行研究
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

至less在我们谈论规范时，JSF 2.2的情况应该会更好。

Answer 10

评论Primefaces / JSF经验的最后几个月：

• 如果你可以使用“现成的”组件，我想这并不可怕。
• 然而，一旦你走出门外需要自定义用户界面，它就不能很好地发挥作用。 – 例如，我们需要为我们的项目使用Twitter的引导程序。 （不是primefaces自举）。
  • 现在我们的网页工作如下：
    • 页面加载。
    • 用户与具有Ajaxfunction的Primefaces进行交互
    • Bootstrap的JavaScript绑定中断
    • 我们运行额外的JavaScript重新绑定一切

JSF避免编写javascript的承诺变成了写入更多的JavaScript，如果不使用Primefaces，那JavaScript将解决Primefaces中断的问题。

这是一个时间下沉 – 除非你再次使用“现货”的东西。 当和Selenium一起工作的时候，也很难看（Primefaces）。 这一切都可以完成 – 但是又一次 – 只有这么多的时间。

如果你正在和UX /devise团队合作，并且需要在UI上快速迭代 – 肯定会避免这种情况 – 你可以通过学习jquery /直接写HTML来节省时间，或者查看反应/angular度。

Answer 11

在所有“主stream”框架（Spring MVC，Wicket，Tapestry等）中，Java EE的JSF及其复合组件是所提供的最详细的表示层组件导向技术。 与HybridJava提供的解决scheme相比，这有点麻烦，有点不完整。

Answer 12

JSF有很多优点，缺点问题让我添加几点。

在一个时间范围内实施一个web项目的实际情况下，你需要关注以下几个因素。

• 你的团队中是否有足够的高级成员可以提出适合每种情况的最佳控制措施？

• 你有带宽来适应最初的学习曲线吗？

• 您的团队中是否有足够的专业知识来审查JSF？
  东西由开发者生产？

如果问题的答案是“否”，那么最终可能会导致不可维护的代码库。

Answer 13

JSF has only one disadvantage: before starting JSF development you should clearly understand web development, core java and frontend architecture.

Now days "new" js frameworks just try to copy/paste JSF component based model .