首页 文章

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

提问于
浏览
227

昨天我看到了一个关于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?

13 回答

  • 0

    JSF 2.0的缺点?老实说,除了相对陡峭的学习曲线,当你没有关于basic Web Development(HTML / CSS / JS,服务器端与客户端等)和basic 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组件树中 . 虽然这是按照规范,但这受到了很多批评 . 另见a.o. JSF/Facelets: why is it not a good idea to mix JSF/Facelets with HTML tags?

    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分隔符来确保生成的HTML输出中HTML元素 id 的唯一性,特别是当组件在视图中重复使用多次时(模板化,迭代组件,等等) . 因为这是CSS标识符中的非法字符,所以您需要使用 \ 来转义CSS选择器中的冒号,从而导致丑陋和奇怪的选择器,如 #formId\:fieldId {} 甚至 #formId\3A fieldId {} . 另请参阅How to use JSF generated HTML element ID with colon ":" in CSS selectors?但是,如果您不是纯粹主义者,请同时阅读By default, JSF generates unusable ids, which are incompatible with css part of web standards .

    此外,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创建自定义组件的功能(所谓的composite components) . 另见Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?

    Ajax功能是在 <f:ajax> 组件的风格中引入的,它与Ajax4jsf有很多相似之处 . 注释和约定优于配置的增强功能尽可能地引入kill详细的 faces-config.xml 文件中 . 此外,默认命名容器ID分隔符 : 变得可配置,因此HTML / CSS纯粹主义者可以放松呼吸 . 您需要做的就是在 web.xml 中将其定义为 init-param ,名称为 javax.faces.SEPARATOR_CHAR ,并确保您不是't using the character yourself anywhere in client ID',例如 - .

    最后但并非最不重要的是,引入了一个新的范围,视图范围 . 它消除了前面描述的另一个主要的JSF 1.x缺点 . 您只需声明bean @ViewScoped 即可启用会话范围,而无需考虑在后续(会话)请求中保留数据的所有方法 . 只要您随后同步或异步(Ajax)提交并导航到同一视图(独立于打开的浏览器选项卡/窗口!), @ViewScoped bean就会存在 . 另见Difference between View and Request scope in managed beansHow to choose the right bean scope?

    虽然JSF 1.x的几乎所有缺点都被消除了,但是JSF 2.0特有的错误可能会成为一个显而易见的问题 . @ViewScoped fails in tag handlers由于鸡蛋问题导致部分省钱 . 这在JSF 2.2中得到修复,并在Mojarra 2.1.18中向后移植 . 另外passing custom attributes like the HTML5 data-xxx不受支持 . 这是通过新的passthrough元素/属性功能在JSF 2.2中修复的 . 此外,JSF实现Mojarra有its own set of issues . 相对而言,很多都与sometimes unintuitive behaviour of ui:repeatnew partial state saving implementationpoorly implemented flash scope相关 . 其中大部分都是在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 and HTML5 support, why is XHTML still being used . 最重要的新JSF 2.2功能是对自定义组件属性的支持,从而打开了一个充满可能性的世界,例如custom tableless radio button groups .

    除了实现特定的错误和一些“烦人的小东西”,例如无法在验证器/转换器中注入EJB(已经在JSF 2.3中修复),JSF 2.2规范中没有真正的主要缺点 .

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

    有些人可能会选择JSF的主要缺点是它允许对生成的HTML / CSS / JS进行非常细致的控制 . 那个's not JSF'是一个基于组件的MVC框架,而不是一个基于请求(动作)的MVC框架 . 如果在考虑MVC框架时高度控制HTML / CSS / JS是您的主要要求,那么您应该已经不是在考虑基于组件的MVC框架,而是在基于请求的MVC框架(如Spring MVC) . 您只需要考虑到您必须自己编写所有HTML / CSS / JS样板文件 . 另见Difference between Request MVC and Component MVC .

    另见:

  • 0

    在与JSF合作5年后,我认为我可以加2美分 .

    两个 major JSF 缺点:

    • 大学习曲线 . JSF很复杂,这是正确的 .

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

    而且 minor 的缺点在我脑海中浮现:

    • 默认情况下,对象的ID由其父项ID组成,例如form1:button1 .

    • 不容易评论错误页面片段的方法 . 标签 <ui:remove> 需要语法正确的内容,无论如何都要解析 .

    • 低质量的第三方组件,例如在继续之前不要在 processXxx() 方法内检查 isRendered() .

    • 合并LESS和Sencha很难 .

    • 与REST不兼容 .

    • 对于UX设计者来说并不那么容易,因为即用型组件有自己的CSS样式,需要覆盖 .

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

    请看看Tapestry,Wicket的低人气和经验丰富的JSF开发人员的低热情(更有意义的是) . 相比之下,看看Rails,Grails,Django,Play的成功!框架 - 它们都是基于行动的,不要试图隐藏网络的程序员 true request/responsestateless nature .

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

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

  • 50

    想到的一些缺点:

    • JSF是一个基于组件的框架 . 这具有与遵守组件模型有关的固有限制 .

    • AFAIK JSF仅支持POST,所以如果你想在某个地方进行GET,你必须做一个普通的servlet / JSP .

    • 大多数组件尝试提供关系数据库和前端JavaScript等域的抽象,很多时候这些抽象都是"leaky"并且很难调试 .

    • 对于初级开发人员或不熟悉某个特定领域的人(例如前端JavaScript)来说,这些抽象可能是一个很好的起点,但是很难对性能进行优化,因为涉及多个层,并且大多数人使用他们对引擎盖下发生的事情几乎一无所知 .

    • 通常与JSF一起使用的模板机制与Web desigers的工作方式无关 . JSF的WYSIWYG编辑器是原始的,无论如何,您的设计师将为您提供HTML / CSS,您将不得不花费多年时间来转换 .

    • 像EL表达式这样的东西没有静态检查,编译器和IDE都没有很好地找到错误,所以你必须在运行时捕获 . 这对于像Ruby或PHP这样的动态类型语言来说可能没问题,但是如果我必须承受Java生态系统的庞大膨胀,我就要求为我的模板键入内容 .

    To sum up: 使用JSF保存的时间,从避免编写JSP / servlet / bean样板代码,您将花费x10来使其扩展并完全按照您的意愿执行操作 .

  • 8

    对我来说,JSF 2.0的最大缺点是不仅是JSF的学习曲线,而是为了让它做有用的工作而必须使用的组件库 . 考虑一下您所处理的规格和标准数量惊人的数量,以确保精通:

    各种形式的

    • HTML . 唐't pretend you don't需要知道它 .

    • 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

    • MyFaces

    • ICEFaces

    • EclipseLink(我的JPA Provider)

    • Hibernate

    • 焊接

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

    • GlassFish(2,3等)

    • JBoss

    • Tomcat

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

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

  • 11

    "JSF will output View-layer HTML and JavaScript that you cannot control or change without going into Controller code."

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

  • 1
    • 没有经验的开发人员通常会创建速度非常慢且代码非常丑陋且难以维护的应用程序 . 它看起来很简单,但如果你想写好的程序,实际上需要一些学习上的投资 .

    • 至少在开始时你经常会遇到一些问题并且会花更多的时间在互联网上阅读balusc帖子而不是实际工作:)过了一会儿它会越来越少,但它仍然可能很烦人 .

    • 当您发现问题不是由于您缺乏知识/错误而实际上是一个错误时,更令人讨厌 . Mojarra(是?)非常错误,另一层组件增加了更多问题 . Richfaces是有史以来最大的废话软件:)不知道它现在是如何在版本4.我们有Primefaces更好,但你仍然会遇到错误或缺乏功能,尤其是更奇特的组件 . 现在您需要为Primefaces更新付费 . 所以我会说它的马车,但它变得更好,特别是在2.2版本修复了规格的一些问题 . 框架越来越成熟,但仍然远非完美(也许myfaces更好?) .

    • 我不是从平均开发人员的角度谈论 - 有截止日期,快速阅读教程和搜索堆栈溢出的问题,因为没有时间去学习它是如何工作的:)通常有些组件似乎有"almost"你需要什么,但不是确切地说,有时你可能会花太多时间让它做你想做的事情:)在评估是否更好地创建自己的或折磨现有组件时需要小心 . 实际上,如果你正在创造一些非常独特的东西,我不会推荐JSF .

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

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

  • 8

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

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

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

    该网站有两个用例:

    • 带网格的页面 . 网格是通过ajax加载的,应该支持排序和分页

    • 三步向导页面 . 每个页面都有客户端验证(用于简单验证)和服务器端ajax基础验证(用于复杂验证) . 任何服务器异常(来自服务层)都应显示在向导的同一页面上,而不导航到下一页 .

    我们发现:

    • 您需要使用omniFaces中的一些hack来修复JSF视图状态 . 当您通过ajax在彼此中包含页面时,JSF状态将被破坏 . 这似乎是JSF中的一个错误,可能会在下一个版本中修复(不在2.3中) .

    • JSF Flow无法正常使用ajax(或者我们无法使其工作!)我们尝试使用primeface向导组件,但客户端验证似乎不受支持,并且意味着它不是标准的JSF流标准 .

    • 当使用jqGird之类的jQuery组件时,你需要这样做加载JSON结果,然后建议您使用纯servlet,JSF将不会为您做任何事情 . 因此,如果您使用这些组件,您的设计将不适合JSF .

    • 当ajax完成 ajaxComplete 时,我们尝试做一些客户端脚本,我们发现PF 4已经实现了自己的ajax事件 . 我们有一些jQuery组件,我们需要更改他们的代码 .

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

    我们总结了我们的研究:

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

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

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

  • 5

    我根本不是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服务器提供服务,则无关紧要 . 我只需要学习一个适用于所有地方的框架 .

    只是我的两分钱 .

  • 451

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

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

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

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

  • 11

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

    • 如果你可以使用组件"off the shelf",我想这并不可怕 .

    • 但是,它并没有为我们的项目提供引导程序 . (不是primefaces bootstrap) .

    • 现在我们的页面工作如下:

    • 页面加载 .

    • 用户与具有ajax功能的Primeface进行交互

    • Bootstrap的javascript绑定中断

    • 我们运行额外的javascript来重新绑定所有内容

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

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

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

  • 22

    JSF有很多优点,问题是处于劣势,让我在其上添加几点 .

    在实施具有时间框架的Web项目的实际场景中,您需要密切关注以下因素 .

    • 您的团队中是否有足够的高级成员可以建议适合每种情况的最佳控制?

    • 您是否有足够的带宽来容纳初始学习曲线?

    • 您是否有足够的专业知识可以审核JSF
      开发商 生产环境 的东西?

    如果您对问题的回答为“否”,则最终可能会出现在不可维护的代码库中 .

  • 18

    JSF只有一个缺点:在开始“JSF”开发之前,你应该清楚地了解web开发,核心Java和前端架构 .

    如今“新”JavaScript框架只是尝试复制/粘贴“JSF”基于组件的模型 .

  • 5

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

相关问题