问题描述

昨天我看到了Java Server Faces 2.0的演示文稿，看起来真的很令人印象深刻，即使我目前是一个快乐的ASP.NET MVC/jQuery Developer.我最喜欢JSF的是最大的Ajax UI组件，似乎比与ASP.NET MVC更快的开发，尤其是在Ajax-Report站点上.集成测试看起来非常好.

因为演示文稿仅强调了JSF的优势，我也想听到另一边.

所以我的问题是:

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

推荐答案

JSF 2.0缺点?老实说，除了关于基本Web开发(HTML/CSS/JS，服务器端与客户端等)和基本java servlet api (请求/响应/会话，转发/重定向等)，没有严重的缺点. JSF在其目前的发布中仍然需要摆脱它在早期期间获得的负面形象，在此期间存在几个严重的缺点.

JSF 1.0(2004年3月)

这是初始版本.它在您不想知道的核心和性能领域的错误杂乱无章.您的WebApplication并不总是在直觉期望的那样工作.你是开发人员会努力哭泣.

JSF 1.1(2004年5月)

这是错误修复版本.表现仍然没有太大改善.还有一个主要缺点:您无法完美地在JSF页面中联机.在 JSF组件树之前，所有普通的vanilla html都获得了.您需要在<f:verbatim>标签中包装所有普通的vanilla，以便它们被包含在JSF组件树中.虽然这是根据规范，但这已经受到了很多批评.另见A.O. JSF/Facelets:为什么将JSF/Facelets与HTML标签混合并不是一个好主意?

JSF 1.2(2006年5月)

这是Ryan Lubke的新JSF开发团队的第一个发布.新团队做了很多伟大的工作.规范也有变化.主要变化是改善观点处理.这不仅完全分离了JSP的JSF，因此可以使用不同的视图技术而不是JSP，但它也允许开发人员在JSF页面中在JSF页面中内联普通Vanilla HTML，而不会抖动<f:verbatim>标签.新团队的另一个主要重点是提高表现.在Sun JSF参考实施的寿命期间(被编号为 Mojarra 以来，2008年左右)，几乎每个构建都在通常(次要)旁边的(次要)错误修正旁边发布(主要)性能改进.

JSF 1.x(包括1.2)的唯一严重缺点是 Request 和 Session 范围之间的范围缺乏范围，所谓的对话范围.这种强迫开发人员与隐藏的输入元素的麻烦，无需在后续请求中保留初始模型数据时，不必要的DB查询和/或滥用会话范围，以便成功地处理验证，转换，模型更改和操作调用.复杂的界面.通过采用第三方库来软化疼痛，它可以在 myfaces tomahawk <t:saveState>组件， jboss seam myfaces orchestra 会话框架.

HTML/CSS的另一个缺点是JSF使用冒号:作为ID分隔字符，以确保HTML元素id在生成的HTML输出中的唯一性，尤其是当组件重复使用时不止一次查看(模板，迭代组件等).由于这是CSS标识符中的非法字符，因此需要使用\以在CSS选择器中转义冒号，从而导致丑陋和奇怪的选择器，如#formId\:fieldId {}甚至#formId\3A fieldId {}.另请参阅如何使用jsf使用CSS选择器中的CSS选择器中生成HTML元素ID”:”，但是，如果您不是纯粹主义者，请阅读By default, JSF generates unusable ids, which are incompatible with css part of web standards.

此外，JSF 1.x没有将Ajax设施与框中的Ajax设施一起发货.不是真正的技术缺点，但由于网络2.0炒作，它成为功能缺点. exadel 早期介绍了Ajax4JSF，这在多年彻底发展并成为 jbossicfaces 组件库.另一个组件库也被包装出来，并且也是众所周知的一个是 Icefaces

大约在JSF 1.2寿命中，介绍了一个新的XML基于XML的视图技术: facelets .这提供了高于JSP的巨大优势，尤其是在模板区域.

JSF 2.0(2009年6月)

这是第二个主要版本，具有ajax作为流行字.有很多技术和功能变化. JSP被Facelets替换，因为默认视图技术和Facelets扩展了使用纯XML创建自定义组件的功能(所谓的复合组件).另请参见为什么Facelets通过JSP优先于JSP作为来自JSF2.0的视图定义语言?

Ajax功率以<f:ajax>组分的风味引入，其与Ajax4JSF具有很多相似之处.引入了注释和泛组 – 过度配置增强功能为 kill verbose faces-config.xml文件尽可能多.此外，默认的命名容器ID分隔符:变为可配置，因此HTML/CSS纯粹主义者可以呼吸缓解.所有您需要做的就是将其定义为web.xml，其中名称javax.faces.SEPARATOR_CHAR并确保您没有在客户端ID中的任何位置使用该角色，例如-.

持续但尚非最不重要的是，引入了一个新的范围，查看范围.如前所述，它消除了另一个主要的JSF 1.x缺点.您只需声明Bean @ViewScoped即可启用对话范围而不会击打后续(会话)请求中保留数据的所有方法.只要您随后提交和导航到同一视图(独立于打开的浏览器选项卡/窗口！)，即同步或异步地(ajax)，bean将居住.另请参见在托管豆类中的视图和请求范围之间的区别 如何选择合适的bean scope?

虽然实际上删除了JSF 1.x的所有缺点，但有JSF 2.0特定错误可能成为一个展示者. @ViewScoped在标签处理程序中失败到期在部分状态储蓄中呈现鸡蛋问题.这在JSF 2.2中固定并在Mojarra 2.1.18中返回.同样传递定制属性，如html5 data-xxx 不支持.通过新的Passthrough Elements/Attributes功能在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的引入，即使这在技术上刚刚支持了所有旧的JSF版本，HTML5也被用作流行语.另请参见 javaServer Faces 2.2和html5支持，为什么xhtml仍在使用.最重要的新JSF 2.2功能是对自定义组件属性的支持，特此开发一个可能性的世界，例如自定义禁止式单选按钮组.

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

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

一些可能选择JSF的主要缺点是它允许对生成的HTML/CSS/JS进行非常小的细粒度控制.这不是JSF自己的，这只是因为它是一种基于组件 MVC框架，而不是基于请求(动作) MVC框架.如果在考虑MVC框架时，如果在考虑MVC框架时，您的主要要求是您的主要要求，那么您应该没有查看基于组件的MVC框架，而是在基于请求的MVC框架(如 spring mvc .您只需要考虑到您必须自己编写所有HTML/CSS/JS Boilerplate.另请参见请求mvc和component mvc 之间的差异.

另请参见:

• JSF，Servlet和JSP之间有什么区别? (只是为了了解基础)
• 使用JSF开发禁止的CSS布局(关于JSF的另一个神话)
• JSF VS普通HTML/CSS/JS/jQuery (当JSF是错误的选择时)
• 在web应用程序中的设计模式(说明了mvc背后的意识形态)

其他推荐答案

5年后使用JSF，我认为我可以添加2美分.

两个主要的JSF 缺点:

1. 大学学习曲线. JSF很复杂，这就是真的.
2. 它组件性质.基于组件的框架尝试隐藏网络的真实性质，这具有大量的并发症和灾难(如不支持在近5年内的JSF).
   
   imho隐藏开发人员的HTTP请求/响应是一个巨大的错误.根据我的经验，每个基于组件的框架都会为Web开发添加抽象，并且该抽象导致不必要的开销和更高的复杂性.

和 minor 缺点来看:

1. 默认情况下，对象的ID由其父母的ID组成，例如Form1:Button1.
2. 没有简单的方法来注释错误的页面的片段. TAG <ui:remove>需要语法上正确的内容，无论如何都会解析.
3. 低质量的第三方组件，例如，在继续之前，请勿检查processXxx()方法中的isRendered().
4. 包含较少和sencha很难.
5. 休息不好.
6. 对UX设计人员来说不是那么容易，因为即用的组件有自己的CSS样式，需要覆盖.

让我不错.由于版本2中的组件框架JSF非常好，但它仍然是基于组件的，并且始终将…

请看看挂毯的低普及，检票口和经验丰富的JSF开发人员的低热情(更为有意义).
为比，看看铁路，Grails，Django，玩的成功！框架 – 他们都是基于动作的，不要试图从程序员 true请求/响应和无状态的web.

对我来说是主要的JSF劣势. IMHO JSF可以适合某种类型的应用程序(Intranet，Forms-Contrence)，但对于现实生活 Web 应用程序，这不是一个好方法.

希望它有助于他/她的选择，以至于前端.

其他推荐答案

一个弹出的缺点:

1. JSF是基于组件的框架.
   这具有固有的限制
   遵守遵守
   组件模型.
2. Afaik JSF支持仅发帖，所以如果您想要在某个地方到达
   做一个普通的servlet/jsp.
3. 大多数组件尝试提供域名的抽象
   关系数据库和前端
   JavaScript，很多时候这些
   抽象是”泄漏”，很难调试.
4. 这些抽象可能是一个初级开发人员的一个很好的起点，也可能是对特定域的不舒服的一个良好的起点(例如前端JavaScript)，但很难优化性能，因为有几个层，而且大多数人使用它们对引擎盖下的事情几乎没有了解.
5. 通常与JSF一起使用的模板机制与网络失望者如何工作无关. JSF的WYSIWYG编辑器是原始的，在任何情况下，您的设计师将为您提供HTML/CSS，以便您必须花费AGES转换.
6. 像El表达式的东西没有静态检查，编译器和IDE都没有在查找错误时做好，因此您将最终在运行时捕获错误.这可能很好地用于类似Ruby或PHP等动态类型的语言，但如果我必须承受Java生态系统的庞大膨胀，我要求键入我的模板.

总结:使用JSF保存的时间，从避免编写JSP/servlet/bean样板代码，您将花费它x10使其缩放并确切地做你想要它做.

以上所述是小编给大家介绍的Java Server Faces 2.0的主要缺点是什么？,希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对77isp云服务器技术网的支持！