Question

我习惯在Struts Framework中工作。那里的事情很简单。 Action类使用从Action Form（代表我的项目中的主要实体）类接收的信息，然后他们继续从一些服务类调用不同的方法。

现在我正在尝试学习JSF，但我无法理解这个框架背后的确切逻辑。我重新编写了一些教程并遵循了一些示例，但它们都关注请求处理生命周期，并且它们使用托管bean和支持bean（每个页面一个）来处理验证，数据库更新等。没有任何行动处理。

我在另一篇文章中听到struts是一个Action Framework，而JSF是一个组件框架，但在我看来，JSF比Struts更麻烦。

我在整个JSF结构中遗漏了什么？

Answer 1

他们使用托管bean和支持bean（每个页面一个）来处理验证，数据库更新等。没有任何行动处理。

这些方法绑定为action和<h:commandLink>的{{1}}属性，它们是真正的操作方法。

E.g。

<h:commandButton>

与

<h:form>
    <h:inputText id="foo" value="#{bean.foo}" required="true" />
    <h:message for="foo" />
    <h:commandButton value="Submit" action="#{bean.submit}" />
</h:form>

请注意，验证应该由@ManagedBean @RequestScoped public class Bean { private String foo; public void submit() { // Here, you're inside the action method! // Save foo in DB or something: someService.save(foo); // Navigate to a different view if necessary. } // Getter+setter. }类完成，而不是在操作方法中完成。

另见：

Our JSF wiki page
Design Patterns web based applications（有关操作与组件的一些信息）
What are the main disadvantages of Java Server Faces 2.0?

Answer 2

你可能认为JSF比Struts更混乱，因为你还没有完全理解它的内部工作原理。

使用基于请求的框架Struts，您必须自己处理很多较低级别的细节。您经常会发现自己跟踪请求参数并与HttpServletRequest和HttpServletResponse对象进行交互。

使用基于组件的框架JSF，已删除了许多较低级别的详细信息。 JSF通过加载bean，执行验证等来为您处理这些细节。您很少需要与请求/响应对象进行交互。

通过抽象掉大量的Servlet细节，JSF允许您更专注于构建模型和操作，而不是请求的细节。通过这种方式，我认为JSF比Struts更清洁 - 而不是更混乱。这样做的缺点是JSF有一个不错的学习曲线。单独使用JSF的开发人员可能仍然不知道如何实际处理请求，这对于了解很有用。

JSF应用程序结构

2 个答案:

另见：