为什么应该避免JSF

长期以来，对我来说，JSF只是另一个我不太在乎的Web框架。这改变了。在被迫使用了几个月之后，我认为在几乎所有情况下，这都是重大的项目风险。在这里，我提出此判决的理由。

UI和处理逻辑的纠缠不清。 官方教程声称以下有关JSF的好处：

Java Server Faces技术的最大优点之一是，它为Web应用程序的行为和表示提供了清晰的分隔。

情况恰恰相反。 Facelets是JSF的首选呈现技术，乍一看就像普通的模板技术一样，例如老式的JSP或Thyme Leaf 。但是，如果您近距离看，恐惧会变得很明显。在构造HTML的同一位置，您还将逻辑放置在操作上应更新UI的哪些部分。我的书中明显违反关注点分离原则。

更好的是， 立即属性可以改变服务器端的生命周期！如果这还不够，则可以根据使用的标签以不同的方式进行处理。你不能做这样的事情。

它尝试抽象您不能抽象的内容。 除了一些奇怪的情况，Web应用程序的客户端和服务器位于相当不同的计算机上，并通过某种网络分隔开来。由此得出一个简单的事实：客户端与服务器之间的通信缓慢且不可靠。 JSF试图抽象化客户端和服务器的分离。它以难以控制的方式处理后端上的所有内容，从而在客户端和服务器之间进行疯狂的通信。结果是，由于使用了JSF，各种故障场景都将突然出现。对我来说，最烦人的就是这个：如果您打开一个JSF页面，比方说一个简单的搜索页面，等待一个小时，然后单击“提交”按钮，您将得到一个异常，因为服务器端状态已过期。 WAT？为什么琐碎的搜索页面的服务器状态没有任何意义？（是的，我知道您可以使用最新版本的JSF更改该行为，但是它仍然是JSF设计的工作方式。）尽管从EJB开始，每个人都学到了以下知识：如果您想对事实进行抽象，如果应用程序有两个部分，是否在同一台计算机上运行，您必须假设它们不在同一台计算机上。其他所有问题都隐藏了问题，直到问题变得如此之大，以至于您可以在早餐中吃掉您的项目。

使事情变得复杂和复杂，从一开始就很容易。 万维网的体系结构很简单。简单含义：它由一小部分概念组成，且交互作用有限。这就是它取得如此广泛成功的原因。对于初学者来说，如何使用它来实现某些功能也不是一件容易的事。我相信我们大多数人都记得他们第一次尝试在没有会话状态的情况下实现购物车之类的东西。但是几乎所有这些问题的解决方案都是众所周知的，也是众所周知的。您所需要的只是一点阅读，而您所获得的是对如何解决此类问题的深刻概念理解。同样，基础非常简单：您将请求发送到URL，并使用HTTP动词发送一些标头和内容。然后您用一些包含链接和一些标题的资源进行回复。而且您在服务器会话中没有状态。使负载平衡和故障转移变得相当简单。使可添加书签的网址变得无关紧要。使您的网站可零成本搜索。使网站易于访问。允许用户根据需要使用其后退按钮，历史记录和标签。拥有精美的URL变得微不足道

将其与JSF的生命周期模型进行比较：用户提交请求的页面将与服务器端的模型同步，然后验证，转换，生成和处理提交的值。如上所述，事物发生的顺序，如果发生的话，则完全由隐藏在伪装为标记的文档中的XML标签控制。除了几乎没有人正确理解所有这些内容（ BalusC似乎是唯一的可用于Interweb的语言）之外，它还对您的应用程序产生以下影响：URL变得丑陋。您将看到源资源的URL，而不是您正在查看的资源的URL，因此使这些URL像在膝盖上的门把手一样有用。与缓存，故障转移，负载平衡等相同。

当然，您可以在这里使用一些约定以及那里的其他库来修复它。当然，当您从事物品破碎业务时，哪种方案才是最合理的选择，所以人们必须为修理它而付费。我个人更喜欢帮助解决实际问题。

阻碍可测试性：我不能说大多数框架，但可以将Spring MVC与JSF进行比较。让我告诉你这一点：如果有人告诉你JSF可以很好地测试，那么他可能不知道自动测试。使用JSF，您可以使用单元测试来测试后端bean。您可以通过将应用程序部署到服务器上并使用Selenium来测试整个UI。基本上就是这样。

以防万一您想知道还有什么可以测试：在浏览器中加载页面的静态版本并使用硒进行测试，以便测试客户端UI行为。测试您生成的标记，而无需启动功能完备的应用程序服务器。测试属性/参数到bean方法的映射。在不引导整个应用程序的情况下测试您生成的标记。使用Spring MVC以及可能使用许多其他合理的服务器端框架，而使用JSF，这一切都是完全可能的。

再说一次：我知道有许多问题的修复程序，但是最简单的修复程序是> 不要使用JSF 。