昨天我看了一个关于Java Server Faces 2.0的演示,它看起来确实令人印象深刻,尽管我现在是一个快乐的ASP。asp.net MVC / jQuery开发。我最喜欢JSF的地方是它有大量支持ajax的UI组件,这使得开发比使用ASP要快得多。NET MVC,特别是在ajax较多的站点上。集成测试看起来也很不错。
由于这个演示只强调了JSF的优点,所以我也想听听其他方面的情况。
所以我的问题是:
Java Server Faces 2.0的主要缺点是什么?
什么会使JSF开发人员考虑使用ASP。NET MVC而不是JSF?
Inexperienced developers usually will create applications that are painfully slow and code will be really ugly and hard to maintain. Its deceptively simple to start, but actually requires some investment in learning if you want to write good programs.
At least at the start you will often "stuck" on some problem and will spend more time reading balusc posts on internet than actually working :) After a while it will be less and less of that, but it still can be annoying.
Even more annoying when you find out that the problem is not due to you lack of knowledge/mistake but actually a bug. Mojarra was(is?) quite buggy, and another layer of components adds even more problems. Richfaces was biggest piece of crap software ever written :) Don't know how it is now on version 4. We have Primefaces which is better, but still you will run into bugs or lack of features especially with more exotic components. And now you will need to pay for Primefaces updates. So I would say its buggy but its getting better especially after 2.2 version fixed some problems with spec. Framework getting more mature but still far from perfect (maybe myfaces better?).
I don't find it especially flexible. Often if you need something very very customized and there are no components that does that - it will be a bit painful. Again I'm talking from average developer perspective - the one with deadlines, quick reading tutorials, and searching stackoverflow when getting stuck because no time to learn how it really works :) Often some components seems to have "almost" what you need, but not exactly and sometimes you might spend too much time to make it do something you want :) Need to be careful in evaluating if its better to create your own or torture existing component. Actually if you are creating something really unique I would not recommend JSF.
简而言之,我的缺点是:复杂,开发过程不流畅,漏洞百出,缺乏灵活性。
当然也有好处,但这不是你问的。不管怎样,这是我使用框架的经验,其他人可能有不同的意见,所以最好的方法是尝试一段时间,看看它是否适合你(只是一些更复杂的东西-不是天真的例子- JSF真的很出色:)依我看,JSF的最佳用例是业务应用程序,如crm等…
我们使用JSF开发了一个示例项目(这是一个为期三周的研究,所以我们可能会丢失一些东西!)
我们尝试使用核心jsf,如果需要组件,我们使用PrimeFaces。
该项目是一个带有导航功能的网站。当点击菜单时,每个页面都应该通过ajax加载。
该网站有两个用例:
带有网格的页面。网格是通过ajax加载的,应该支持排序和分页
一个三步向导页面。每个页面都有客户端验证(用于简单验证)和服务器端ajax基础验证(用于复杂验证)。任何服务器异常(来自服务层)应该显示在向导的同一页上,而不需要导航到下一页。
我们发现:
You need to use some hacks from omniFaces to make the JSF view state fixed. The JSF state will be corrupted when you include pages via ajax in each other. This seems a bug in JSF and may be fixed on next releases (not in 2.3).
The JSF Flow is not working correctly with ajax (or we could not make it work!) We try to use primeface wizard component instead but the client validation seems not supported and mean while it was not standard JSF flow standard.
When using some jQuery components like jqGird, and you need to load JSON results, then you are advised to use pure servlet, The JSF will do nothing for you. So if you use these kind of components, your design will not fit in JSF.
We try to do some client scripts when ajax complete by ajaxComplete and we found that the PF 4 has implemented its own ajax events. We had some jQuery components and we need to change their code.
如果您将上面的示例更改为非Ajax项目(或至少是较少的Ajax项目),您将不会面临上述许多问题。
我们将我们的研究总结为:
JSF在一个完全基于ajax的网站上不能很好地工作。
当然,我们发现JSF中有很多不错的特性,这些特性在某些项目中可能非常有用,所以请考虑您的项目需求。
请参考JSF技术文档来回顾JSF的优点,在我看来JSF最大的优点是来自@BalusC的完全和巨大的支持;-)
评论我过去几个月的Primefaces/JSF体验:
如果你可以使用“现成的”组件,我想这并不可怕。
然而,当你走到外面并需要定制ui时,它就不能很好地发挥作用。-例如,我们需要在项目中使用Twitter的bootstrap。(不是primefaces bootstrap)。
现在我们的页面工作如下:
页面加载。
用户与具有ajax功能的Primefaces交互
Bootstrap的javascript绑定中断
我们运行额外的javascript来重新绑定所有内容
JSF避免编写javascript的承诺变成了编写比不使用Primefaces时更多的javascript——而javascript是用来修复Primefaces破坏的。
这是一个时间消耗器——除非你再次使用现成的东西。当不得不与Selenium一起工作时,也非常丑陋(Primefaces)。这些都是可以做到的,但是时间有限。
如果你和UX/设计团队一起工作,并且需要快速迭代UI,你可以通过学习jquery/编写直接的HTML来节省时间,或者查看react/angular。
我想到了一些缺点:
JSF is a component-based framework.
This has inherent restrictions that
have to do with obeying the
component-model.
AFAIK JSF supports only POST, so if you want a GET somewhere you have
to do a plain servlet/JSP.
Most components try to provide abstractions over domains like
relational databases and front-end
JavaScript, and many time these
abstractions are "leaky" and very hard to debug.
These abstractions might be a good starting point for a junior developer or someone not comfortable with a particular domain (e.g. front-end JavaScript), but are very hard to optimise for performance, since there are several layers involved, and most people that use them have little understanding of what is going on under the hood.
The templating mechanisms that are usually used with JSF have nothing to do with how web desigers work. The WYSIWYG editors for JSF are primitive and in any case, your designer will give you HTML/CSS that you'll have to spend ages converting.
Things like EL expressions are not statically checked and both the compiler and IDEs are not doing a good job at finding errors, so you'll end up with errors that you'll have to catch at run-time. This might be fine for dynamically typed language like Ruby or PHP, but if I have to withstand the sheer bloat of the Java ecosystem, I demand typing for my templates.
总而言之:使用JSF节省的时间,从避免编写JSP/servlet/bean样板代码,您将花费10倍的时间来使其可伸缩并完全按照您的要求进行操作。