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

Question

昨天我看到了一个关于Java Server Faces 2.0的演示文稿,虽然我现在是一个快乐的ASP.NET MVC/jQuery开发人员,但它看起来确实令人印象深刻.我最喜欢JSF的是大量支持AJAX的UI组件,这些组件似乎比ASP.NET MVC更快,特别是在AJAX重型站点上.集成测试看起来也很不错.

由于演示文稿只强调了JSF的优点,我也想听听另一方面的意见.

所以我的问题是:

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

Answer 1

JSF 2.0的缺点？老实说,除了相对陡峭的学习曲线,当你没有关于基本Web开发(HTML/CSS/JS,服务器端与客户端等)和基本Java Servlet API(请求/响应/会话)的扎实背景知识,转发/重定向等),没有严重的缺点想到.JSF在其当前版本中仍然需要摆脱它在早期阶段所获得的负面形象,在此期间存在几个严重的缺点.

JSF 1.0(2004年3月)

这是最初的版本.它在你不想知道的核心和性能领域都是杂乱无章的.您的Web应用程序并不总是按照您的直觉期望工作.你作为开发人员会痛苦地哭泣.

JSF 1.1(2004年5月)

这是bug修复版.表现仍然没有太大改善.还有一个主要缺点:您无法在JSF页面中完美地内联HTML.所有普通的vanilla HTML都在 JSF组件树之前呈现.您需要将所有普通vanilla包装在<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年左右开始,代号为Mojarra,自2008年左右开始),实际上每个版本都会在通常(次要)错误修正旁边进行(主要)性能改进.

JSF 1.x(包括1.2)的唯一严重缺点是请求和会话范围之间缺乏范围,即所谓的会话范围.这会迫使开发人员在需要在后续请求中保留初始模型数据时为隐藏的输入元素,不必要的数据库查询和/或滥用会话范围而烦恼,以便成功地处理更多的验证,转换,模型更改和操作调用复杂的网络应用.采用第三方库可以缓解痛苦,第三方库在后续请求中保留必要的数据,如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,这与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(所谓的复合组件)创建自定义组件的功能.另请参阅为什么Facelets优于JSP作为JSF2.0以后的视图定义语言？

Ajax功能是在<f:ajax>组件的味道中引入的,与Ajax4jsf有很多相似之处.注释和约定优于配置的增强被引入杀冗长的faces-config.xml文件尽可能.此外,默认的命名容器ID分隔符字符:变得可配置,因此HTML/CSS纯粹主义者可以放心.所有你需要做的是将其定义为init-param在web.xml与名称javax.faces.SEPARATOR_CHAR,并确保你是不是自己使用的角色在任何地方的客户端ID的,如-.

最后但并非最不重要的是,引入了一个新的范围,视图范围.它消除了前面描述的另一个主要的JSF 1.x缺点.您只需声明bean @ViewScoped以启用会话范围,而无需考虑在后续(会话)请求中保留数据的所有方法.一个@ViewScoped只要bean将居住作为你随后提交并导航到同一个视图(独立打开浏览器标签/窗口!),同步或异步(阿贾克斯).另请参阅托管bean中的View和Request范围之间的区别以及如何选择正确的bean范围？

虽然JSF 1.x的几乎所有缺点都被消除了,但是JSF 2.0特有的错误可能会成为一个显而易见的问题.将@ViewScoped在标签处理失败是由于部分国家储蓄鸡-蛋的问题.这在JSF 2.2中得到修复,并在Mojarra 2.1.18中向后移植.还通过自定义属性,如HTML5data-xxx不支持.这是通过新的passthrough元素/属性功能在JSF 2.2中修复的.此外,JSF实现Mojarra有自己的一系列问题.相对而言,其中很多都与有时不直观的行为有关<ui:repeat>,新的部分状态保存实现和实施不当的闪存范围.其中大部分都是在Mojarra 2.2.x版本中修复的.

在JSF 2.0时代,基于jQuery和jQuery UI引入了PrimeFaces.它成为最流行的JSF组件库.

JSF 2.2(2013年5月)

随着JSF 2.2的引入,HTML5被用作流行语,尽管这在技术上只是在所有旧的JSF版本中得到支持.另请参阅JavaServer Faces 2.2和HTML5支持,为什么仍在使用XHTML.最重要的新JSF 2.2功能是对自定义组件属性的支持,从而打开了各种可能性,例如自定义无表格单选按钮组.

除了实现特定的错误和一些"烦人的小东西",例如无法在验证器/转换器中注入EJB(已经在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背后的意识形态)

Answer 2

在与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样式,需要覆盖.

别误会我的意思.作为一个组件框架,版本2中的JSF非常好,但它仍然是基于组件的,并且总是......

请看看Tapestry,Wicket的低人气和经验丰富的JSF开发人员的低热情(更有意义的是).相比之下,看看Rails,Grails,Django,Play的成功!框架 - 它们都是基于行动的,并不试图隐藏程序员的真实请求/响应和Web的无状态特性.

对我来说这是JSF的主要缺点.IMHO JSF可以适合某种类型的应用程序(内联网,表单密集型),但对于真实的Web应用程序来说,这不是一个好方法.

希望它能帮助某些人选择与前端有关的选择.

Answer 3

想到的一些缺点:

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样板代码开始,您将花费x10来使其扩展并完全按照您的意愿执行操作.

Answer 4

对我来说,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,当你在它.
• Context Dependency Injection规范(CDI)以及它与JSF 2.0的冲突和使用方式
• JQuery - 我希望看到你在没有它的情况下相处.

现在,一旦完成,您就可以继续使用专有规范,即您将在此过程中获取的组件库和提供程序库:

• PrimeFaces(我选择的组件库)
• RichFaces的
• MyFaces的
• ICEFaces的
• EclipseLink(我的JPA Provider)
• 过冬
• 焊接

不要忘记容器!以及所有这些配置文件:

• GlassFish(2,3等)
• JBoss的
• Tomcat的

那么 - 这让它变得容易吗？当然,只要您想要做的只是最简单的交互的最基本的网页,JSF 2.0是"简单的".

简而言之,JSF 2.0是当今软件世界中存在的最复杂,最繁琐的粘合技术.我想不出任何我宁愿使用的东西.

Answer 5

1. 没有经验的开发人员通常会创建速度非常慢且代码非常丑陋且难以维护的应用程序.它看起来很简单,但如果你想写好的程序,实际上需要一些学习上的投资.
2. 至少在一开始你会经常"卡住"一些问题并且会花更多的时间在互联网上阅读balusc帖子而不是实际工作:)过了一段时间它会越来越少,但它仍然可能很烦人.
3. 当您发现问题不是由于您缺乏知识/错误而实际上是一个错误时,更烦人.Mojarra(是？)非常错误,另一层组件增加了更多问题.Richfaces是有史以来最大的废话软件:)不知道它现在是如何在版本4.我们有Primefaces更好,但你仍然会遇到错误或缺乏功能,尤其是更奇特的组件.现在您需要为Primefaces更新付费.所以我会说它的马车,但它变得更好,特别是在2.2版本修复了规格的一些问题.框架越来越成熟,但仍然远非完美(也许myfaces更好？).
4. 我觉得它不是特别灵活.通常,如果你需要非常定制的东西,并且没有任何组件可以做到这一点 - 那将会有点痛苦.我再次从平均开发人员的角度谈论 - 有截止日期,快速阅读教程和搜索堆栈溢出的问题,因为没有时间来了解它是如何工作的:)通常一些组件似乎"几乎"你需要的东西,但是不完全有时你可能会花太多时间让它做你想做的事情:)在评估是否更好地创建自己的或折磨现有组件时需要小心.实际上,如果你正在创造一些非常独特的东西,我不会推荐JSF.

所以简而言之,我的缺点是:复杂性,不是非常顺利的开发进度,错误,不灵活.

当然也有优点,但那不是你问的.无论如何,这是我对框架的经验其他人可能会有不同的意见,所以最好的方法是尝试一段时间,看看它是否适合你(只是更复杂的东西 - 不是天真的例子 - JSF真的在那里闪耀:)恕我直言最好的用例JSF是业务应用程序,如CRM等...

Answer 6

"JSF将输出您无法控制或更改的视图层HTML和JavaScript,而无需进入Controller代码."

实际上JSF为您提供了灵活性,您可以使用标准/第三方组件或创建自己的组件,您可以完全控制所呈现的内容.使用JSF 2.0创建自定义组件只需要一个xhtml.

Answer 7

我们用JSF开发了一个示例项目(这是一个为期三周的研究,所以我们可能会丢失一些东西!)

我们尝试使用核心jsf,如果需要一个组件,我们使用PrimeFaces.

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

该网站有两个用例:

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

我们发现:

1. 您需要使用omniFaces中的一些hack来修复JSF视图状态.当您通过ajax在彼此中包含页面时,JSF状态将被破坏.这似乎是JSF中的一个错误,可能会在下一个版本中修复(不在2.3中).
2. JSF Flow无法正常使用ajax(或者我们无法使其工作!)我们尝试使用primeface向导组件,但客户端验证似乎不受支持,并且意味着它不是标准的JSF流标准.
3. 当使用jqGird等一些jQuery组件时,你需要加载JSON结果,然后建议你使用纯servlet,JSF将不会为你做任何事情.因此,如果您使用这些组件,您的设计将不适合JSF.
4. 当ajax完成时我们尝试做一些客户端脚本ajaxComplete,我们发现PF 4已经实现了自己的ajax事件.我们有一些jQuery组件,我们需要更改他们的代码.

如果您将上述示例更改为非Ajax项目(或至少减少ajax项目),您将不会遇到很多上述问题.

我们总结了我们的研究:

JSF在完全ajax基础网站上运行不佳.

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

请参考JSF技术文档来回顾JSF的优势,在我看来,JSF的最大优势是来自@BalusC的完整和巨大的支持;-)

Answer 8

我根本不是Java Server Faces专家.但恕我直言,主要的缺点是它的服务器端.我厌倦了学习和使用服务器端Web表示层框架,如ASP.NET Web Forms,ASP.NET MVC,Java Server Faces,Struts,php框架和ruby on rails框架.我告别了所有人,我向Angularjs和TypeScript问好.我的表示层在浏览器上运行.如果由运行php或ASP.NET的Windows IIS提供服务,或者它是由运行在Linux上的Apache Web服务器提供服务,则无关紧要.我只需要学习一个适用于所有地方的框架.

只是我的两分钱.

Answer 9

对我来说,JSF最大的缺点是对编程(动态)生成的页面的支持不足.
如果要从java代码动态构建页面(创建页面组件模型).例如,如果您正在使用WYSIWYG网页构造函数.通常不提供此用例的充分文档.有很多方面你需要进行实验,开发速度很慢.许多事情根本无法实现.但通常它可能以某种方式破解它.
好的是,它在JSF的哲学或架构中不是问题.它根本没有详细说明(据我所知).

JSF 2带来了复合组件,这应该使组件开发变得容易,但它们对动态(程序化)构造的支持非常差.如果您克服了动态复合组件构造的安静复杂且几乎未记录的过程,您会发现如果将较少的复合组件嵌套得更深,它们会停止工作,抛出一些例外.

但似乎JSF社区意识到了这个缺点.从这两个错误可以看出他们正在研究这个问题
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

至少如果我们谈论规范,JSF 2.2的情况应该更好.

Answer 10

评论我最近几个月的Primefaces/JSF经历:

• 如果你可以使用"现成的"组件,我想这并不可怕.
• 但是,只要您走出去并需要自定义UI,它就无法很好地发挥作用. - 例如,我们需要在我们的项目中使用Twitter的引导程序.(不是primefaces bootstrap).
  • 现在我们的页面工作如下:
    • 页面加载.
    • 用户与具有ajax功能的Primeface交互
    • Bootstrap的javascript绑定中断
    • 我们运行额外的javascript来重新绑定一切

JSF避免编写javascript的承诺变成了编写更多的javascript,而不是使用Primefaces - 并且javascript来修复Primefaces破坏的内容.

这是一个时间下沉 - 除非你再次使用"现成的"东西.当与Selenium合作时,也非常丑陋(Primefaces).这一切都可以完成 - 但同样 - 只有那么多时间.

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