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

昨天，尽管我目前是一名快乐的ASP.NET MVC / jQuery开发人员，但我看到了有关Java Server Faces 2.0的演示，该演示看上去确实令人印象深刻。我最喜欢JSF的地方是大量支持AJAX的UI组件，这些组件似乎使开发速度比使用ASP.NET MVC快得多，尤其是在AJAX繁重的网站上。集成测试也看起来非常不错。

由于演示文稿仅强调了JSF的优点，因此我也想听听另一面的信息。

所以我的问题是：

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

JSF 2.0的缺点？老实说，除了您对基本的Web开发（HTML / CSS / JS，服务器端与客户端等）和基本Java Servlet API（请求/响应/会话）没有扎实的背景知识以外，相对的学习曲线比较陡峭，转发/重定向等），就不会出现严重的不利影响。JSF当前版本仍然需要摆脱早期获得的负面印象，在此期间存在一些严重的缺点。

JSF 1.0（2004年3月）

这是最初的版本。您不希望知道的核心和性能方面的错误使它杂乱无章。您的Web应用程序并非总是能如您所愿地工作。作为开发人员，您会大哭一场。

JSF 1.1（2004年5月）

这是错误修正版本。性能仍然没有太大提高。还有一个主要缺点：您不能完美地在JSF页面中内联HTML。所有普通的原始HTML都在 JSF组件树之前呈现。您需要将所有普通香草包装在<f:verbatim>标签中，以便它们包含在JSF组件树中。尽管这是按照规范进行的，但这引起了很多批评。另请参见JSF / Facelets：为什么将JSF / Facelets与HTML标记混合不是一个好主意？

JSF 1.2（2006年5月）

这是Ryan Lubke领导的新JSF开发团队的第一个版本。新团队做了很多出色的工作。规格也有变化。主要变化是视图处理的改进。这不仅使JSF与JSP完全分离，因此可以使用与JSP不同的视图技术，而且还允许开发人员在JSF页面中内嵌普通的HTML，而不会产生<f:verbatim>标签麻烦。新团队的另一个主要重点是提高绩效。在Sun JSF参考实现1.2的生命周期内（自2008年左右的build 1.2_08起，它的代号为Mojarra），几乎每个构建都在（通常）（次要）错误修复之后交付了（主要）性能改进。

JSF 1.x（包括1.2）的唯一严重缺点是在请求范围和会话范围之间缺乏范围，即所谓的对话范围。每当有人想要在后续请求中保留初始模型数据以成功处理验证，转换，模型更改和操作调用时，这迫使开发人员不得不为隐藏的输入元素，不必要的数据库查询和/或滥用会话范围而烦恼。复杂的Web应用程序。可以通过采用第三方库来减轻这种痛苦，该库在后续请求中保留了必要的数据，例如MyFaces Tomahawk <t:saveState>组件，JBoss Seam对话范围和MyFaces Orchestra。 对话框架。

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

而且，JSF 1.x并没有附带Ajax功能。这并不是真正的技术劣势，但是由于在此期间对Web 2.0的炒作，使其成为功能劣势。Exadel早就引入了Ajax4jsf，它在过去的几年中进行了全面的开发，并成为JBoss RichFaces组件库的核心部分。另一个组件库也附带了内置的Ajax功能，众所周知的是ICEfaces。

在JSF 1.2生命周期的一半左右，引入了一种新的基于XML的视图技术：Facelets。这提供了超越JSP的巨大优势，尤其是在模板领域。

JSF 2.0（2009年6月）

这是第二个主要版本，以Ajax为流行语。有很多技术和功能更改。JSP被Facelets取代为默认视图技术，Facelets进行了扩展，具有使用纯XML创建自定义组件的功能（所谓的复合组件）。另请参见为什么从JSF2.0起，Facelets比JSP更优选作为视图定义语言？

在<f:ajax>组件的风格方面引入了Ajax功能，该功能与Ajax4jsf有很多相似之处。引入了注释和约定优于配置的增强功能，以尽可能地消除详细faces-config.xml文件。同样，默认的命名容器ID分隔符:也可以配置，因此HTML / CSS纯粹主义者可以放心使用。所有你需要做的是将其定义为init-param在web.xml与名称javax.faces.SEPARATOR_CHAR，你是不是自己使用的角色在任何地方的客户端ID的，比如和确保-。

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

尽管实际上消除了JSF 1.x的所有缺点，但是仍有一些JSF 2.0特定的错误可能成为热门。将@ViewScoped在标签处理失败是由于部分国家储蓄鸡-蛋的问题。此问题在JSF 2.2中已修复，在Mojarra 2.1.18中已向后移植。同样不支持传递自定义属性，例如HTML5data-xxx。在JSF 2.2中，此问题已通过新的直通元素/属性功能修复。此外，JSF的实现Mojarra有其自身的问题。相对而言，它们中的许多都与有时不直观的行为<ui:repeat>，新的部分状态保存实现以及Flash范围实现不佳有关。其中大多数已在Mojarra 2.2.x版本中修复。

在JSF 2.0时代左右，基于jQuery和jQuery UI引入了PrimeFaces。它成为最受欢迎的JSF组件库。

JSF 2.2（2013年5月）

随着JSF 2.2的引入，尽管从技术上讲，所有较旧的JSF版本都支持HTML5，但HTML5却被用作流行语。另请参阅JavaServer Faces 2.2和HTML5支持，为什么仍在使用XHTML。JSF 2.2最重要的新功能是对自定义组件属性的支持，从而开辟了无限可能，例如自定义无表单选按钮组。

除了特定于实现的错误和一些“烦人的小事情”（例如无法将Java注入验证器/转换器（已在JSF 2.3中修复））之外，JSF 2.2规范并没有真正的主要缺点。

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

有些人可能会选择JSF的主要缺点是，它几乎不对生成的HTML / CSS / JS进行细粒度的控制。那不是JSF自己的，仅仅是因为它是基于组件的 MVC框架，而不是基于请求（动作）的 MVC框架。如果在考虑MVC框架时对HTML / CSS / JS的高度控制是您的主要要求，那么您应该已经不是在研究基于组件的MVC框架，而是在基于请求的MVC框架（例如Spring MVC）。您只需要考虑必须自己编写所有HTML / CSS / JS样板文件。另请参见请求MVC和组件MVC之间的区别。

也可以看看：

• JSF，Servlet和JSP有什么区别？（只是为了了解基础知识）
• 使用JSF开发无表CSS布局（关于JSF的另一个神话）
• JSF与普通HTML / CSS / JS / jQuery（当JSF是错误的选择时）
• Web应用程序中的设计模式（说明了MVC背后的思想）

在与JSF合作5年之后，我认为我可以多付2美分。

JSF的两个主要缺点：

1. 学习曲线大。JSF很复杂，这是事实。
2. 其组成性质。基于组件的框架试图掩盖Web的真实本质，它伴随着大量的复杂性和灾难（例如在近5年内不支持JSF中的GET）。
   恕我直言，向开发人员隐藏HTTP请求/响应是一个巨大的错误。根据我的经验，每个基于组件的框架都将抽象添加到Web开发中，这种抽象导致不必要的开销和更高的复杂性。

我想到的还有一些小缺点：

1. 默认情况下，对象的ID由其父代的ID组成，例如form1：button1。
2. 没有简单的方法来注释掉不正确页面的片段。标记<ui:remove>需要语法正确的内容，无论如何都要对其进行解析。
3. 低质量的第三方组件，例如，在继续操作之前不检查isRendered()内部processXxx()方法。
4. 合并LESS＆Sencha很难。
5. 与REST搭配使用效果不佳。
6. 对于UX设计人员而言，这并不容易，因为现成的组件具有其自己的CSS样式，需要重写。

不要误会我的意思。作为一个组件框架，JSF版本2确实不错，但是它仍然是基于组件的，并且永远都是...

请查看Tapestry，Wicket的普及程度低以及经验丰富的JSF开发人员的热情低落（更有意义的地方）。相比之下，请看一下Rails，Grails，Django和Play的成功！框架-它们都是基于动作的，不会试图向程序员隐藏真正的请求/响应和Web的无状态本质。

对我来说，这是JSF的主要缺点。IMHO JSF可以适合某些类型的应用程序（内部网，表单密集型），但是对于实际的Web应用程序来说，这不是一个好方法。

希望它有助于某人选择与前端有关的内容。

我想到了一些缺点：

1. JSF是基于组件的框架。这具有与遵守组件模型有关的固有限制。
2. AFAIK JSF仅支持POST，因此，如果要在某个地方进行GET，则必须执行简单的servlet / JSP。
3. 大多数组件都试图在诸如关系数据库和前端JavaScript之类的域上提供抽象，而且很多时候这些抽象是“泄漏的”并且很难调试。
4. 对于初级开发人员或不熟悉特定领域的人员（例如前端JavaScript）而言，这些抽象可能是一个很好的起点，但是由于涉及多个层次，并且大多数人都在使用它们，因此很难对其性能进行优化。对引擎盖下发生的事情几乎一无所知。
5. JSF通常使用的模板机制与Web设计器的工作方式无关。JSF的WYSIWYG编辑器是原始的，无论如何，您的设计师都会为您提供HTML / CSS，您需要花很多时间进行转换。
6. 诸如EL表达式之类的内容不会被静态检查，并且编译器和IDE都无法很好地发现错误，因此最终将导致在运行时必须捕获的错误。这对于像Ruby或PHP这样的动态类型化语言来说可能很好，但是如果我不得不承受Java生态系统的巨大膨胀，我需要为模板进行类型化。

总结：使用JSF可以节省时间，避免编写JSP / servlet / bean样板代码，您将花10倍的时间使其扩展并完全按照自己的意愿进行操作。

对我而言，JSF 2.0的最大缺点不仅是JSF的学习曲线，还在于您必须使用它才能进行有用的工作的组件库。考虑一下要真正精通的大量规范和标准：

• HTML中的各种形式。不要假装你不需要知道它。
• HTTP-当您不知道发生了什么时，您必须打开Firebug看看。为此，您需要知道这一点。
• CSS-喜欢与否。确实还不错，至少有一些不错的工具。
• XML –在这种程度上，JSF可能是您首先使用名称空间的地方。
• Servlet规范。迟早您将进入此程序包中的调用方法。除此之外，您还必须知道Facelets如何变成XHTML或类似的东西。
• JSP（主要是因为您知道为什么在JSF中不需要它）
• JSTL（再次，主要是为了处理遗留框架）
• 各种形式的表达语言（EL）。
• ECMAScript，JavaScript或您要调用的其他名称。
• JSON-即使您不使用它，也应该知道这一点。
• AJAX。我想说JSF 2.0在将其隐藏起来方面做得不错，但是您仍然需要知道发生了什么。
• DOM。以及浏览器如何使用它。请参阅ECMAScript。
• DOM事件-本身就是一个主题。
• Java持久性体系结构（JPA），如果您希望您的应用程序具有任何后端数据库。
• Java本身。
• 当您使用JSEE时。
• 上下文依赖注入规范（CDI）及其与JSF 2.0的冲突和使用
• jQuery-我希望看到没有它的人相处得很好。

现在，一旦完成，就可以继续使用专有规范，即组件库和提供程序库：

• PrimeFaces（我选择的组件库）
• RichFaces
• 我的脸
• 交流会
• EclipseLink（我的JPA提供商）
• 冬眠
• 焊接

并且不要忘记容器！以及所有这些配置文件：

• GlassFish（2、3等）
• 老板
• 雄猫

所以-这很容易吗？当然，只要您要做的就是交互最简单的最基本的Web页面，JSF 2.0就是“轻松”的。

简而言之，JSF 2.0是当今软件领域中最复杂，最繁琐的胶合技术。而且我想不出我想使用的任何东西。

1. 没有经验的开发人员通常会创建速度非常慢的应用程序，并且代码将非常难看且难以维护。它看似简单，但是要想编写好的程序，实际上需要在学习上进行一些投资。
2. 至少在开始时，您经常会“卡在”某个问题上，并花费更多的时间在互联网上阅读栏杆文章，而不是实际工作：)一段时间后，它会越来越少，但仍然很烦人。
3. 当您发现问题并不是由于您缺乏知识/错误而引起的，而是实际上是一个错误时，这会更加烦人。Mojarra确实是越野车，而另一层组件增加了更多问题。Richfaces是有史以来编写的最大的废话软件：)不知道它在第4版中的情况如何。我们拥有更好的Primefaces，但是您仍然会遇到bug或缺少功能，尤其是使用更多奇特的组件时。现在，您将需要为Primefaces更新付费。因此，我想说它的错误，但是尤其在2.2版本修复了规范方面的某些问题之后，它变得越来越好。框架变得越来越成熟，但还远远不够完美（也许myfaces更好？）。
4. 我觉得它不是特别灵活。通常，如果您需要非常非常定制的东西，并且没有可以执行此操作的组件-这会有些痛苦。再次，我从普通的开发人员的角度进行讨论-具有截止日期，快速阅读教程以及在卡住时搜索stackoverflow的观点，因为没有时间了解它的真正工作原理：)通常某些组件似乎“几乎”具有了您所需要的，但是可能不完全正确，有时您可能会花费太多时间使它做您想做的事情：)在评估创建自己的组件或折磨现有组件是否更好时需要谨慎。实际上，如果您要创建真正独特的东西，我不建议您使用JSF。

简而言之，我的缺点是：复杂性，开发进度不够顺利，越野车，缺乏灵活性。

当然也有优点，但这不是您要的。无论如何，根据我在框架方面的经验，其他人可能会有不同的意见，所以最好的方法是尝试一会儿，看看它是否适合您（只是更复杂-不是幼稚的示例-JSF确实在这里闪耀：） IMHO最佳用例JSF是业务应用程序，例如CRM等。

“ JSF将输出您在不进入Controller代码的情况下无法控制或更改的View层HTML和JavaScript。”

实际上，JSF为您提供了灵活性，您可以使用标准/第三方组件，也可以创建自己的组件，并对呈现的内容完全控制。这只是使用JSF 2.0创建自定义组件所需要的xhtml。

我根本不是Java Server Faces专家。但是恕我直言，主要缺点是它在服务器端。我已经厌倦了学习和使用服务器端Web表示层框架，例如ASP.NET Web窗体，ASP.NET MVC，Java Server Faces，Struts，php框架和ruby on rails框架。我向所有人告别，并向Angularjs和TypeScript打招呼。我的表示层在浏览器上运行。我不关心它是由运行php或ASP.NET的Windows IIS提供服务，还是由在Linux上运行的Apache Web服务器提供服务。我只需要学习一个可以在任何地方使用的框架。

只是我的两分钱。

我们与JSF开发了一个示例项目（这是一个为期三周的研究，因此我们可能会失去一些东西！）

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

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

该站点有两个用例：

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

我们发现：

1. 您需要使用来自omniFaces的一些技巧来修复JSF视图状态。当您通过ajax相互包含页面时，JSF状态将被破坏。这似乎是JSF中的错误，并且可能会在以后的版本中修复（不在2.3中）。
2. JSF Flow无法与ajax一起正常工作（否则我们无法使其正常工作！）我们尝试改为使用primeface向导组件，但似乎不支持客户端验证，这意味着它不是标准的JSF Flow标准。
3. 当使用jqGird之类的jQuery组件时，您需要加载JSON结果，那么建议您使用纯servlet，JSF不会为您做任何事情。因此，如果您使用这些类型的组件，则您的设计将不适用于JSF。
4. 当ajax完成时，我们尝试做一些客户端脚本ajaxComplete，我们发现PF 4已经实现了自己的ajax事件。我们有一些jQuery组件，我们需要更改其代码。

如果将以上示例更改为非Ajax项目（或至少更少的ajax项目），则不会遇到很多上述问题。

我们将研究总结为：

JSF在完全基于ajax的网站中运行不佳。

当然，我们在JSF中发现了许多不错的功能，这些功能在某些项目中可能非常有用，因此请考虑您的项目需求。

请参阅JSF技术文档以回顾JSF的优势，我认为JSF的最大优势是@BalusC的COMPLETE AND HUGE支持；-)

对我来说，JSF的最大缺点是对以编程方式（动态）生成的页面的支持不佳。
如果要从Java代码动态构建页面（创建页面组件模型）。例如，如果您正在使用所见即所得的Web页面构造函数。通常无法获得此用例的足够文档。在很多地方，您必须进行试验，并且开发速度非常缓慢。许多事情只是无法按预期工作。但是通常它可能会以某种方式破解。
好消息是，这不是JSF的哲学或体系结构问题。据我所知，它根本不够详细。

JSF 2带来了Composite Components，它应该使组件开发变得容易，但是它们对动态（程序）构造的支持非常差。如果您克服了动态复合组件构建过程中安静，复杂且几乎没有文献记载的过程，那么您会发现，如果将一些复合组件嵌套得更深，它们将停止工作，并引发一些异常。

但是，似乎JSF社区意识到了这一缺点。正如您从这两个错误中看到的那样，他们正在为此工作
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

至少如果我们在谈论规范，JSF 2.2的情况应该更好。

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

• 如果您可以“现成”使用组件，那么我认为这并不可怕。
• 但是，一旦您退出并需要自定义UI，它就无法很好地发挥作用。-例如，我们需要在项目中使用Twitter的引导程序。（不是primefaces引导程序）。
  • 现在我们的页面工作如下：
    • 页面加载。
    • 用户与具有ajax功能的Primefaces进行交互
    • Bootstrap的javascript绑定中断
    • 我们运行额外的JavaScript重新绑定所有内容

JSF避免编写JavaScript的承诺变成了编写更多的JavaScript，这比不使用Primefaces编写的JavaScript要多-并且该JavaScript可以解决Primefaces的不足。

这是一个时间浪费-除非您再次使用“现成的”东西。当必须与Selenium一起使用时，也真的很难看（Primefaces）。可以完成所有工作，但是再一次，只有那么多时间。

如果您正在与UX /设计团队合作并且需要快速迭代UI，那么绝对可以避免这种情况-您可以通过学习jquery /编写纯HTML或查看react / angular来节省时间。

JSF有很多优点，而在不利方面的问题让我在上面加几点。

在一定时间范围内实施Web项目的实际情况下，您需要注意以下因素。

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

• 您有足够的带宽来适应初始学习曲线吗？

• 您的团队中是否有足够的专业知识，可以审查
  开发人员生产的JSF 产品？

如果您对这些问题的回答为“否”，那么您可能会陷入无法维护的代码库中。

JSF仅有一个缺点：在开始“ JSF”开发之前，您应该清楚地了解Web开发，核心Java和前端体系结构。

如今，“新” JavaScript框架仅尝试复制/粘贴基于组件的“ JSF”模型。

在诸如Spring MVC，Wicket，Tapestry等所有“主流”框架中，Java EE的JSF及其复合组件是所提供的最详尽的表示层和面向组件的技术。与HybridJava提供的解决方案相比，这有点麻烦且不完整。