将 JSF 理解为 MVC 框架答案

【问题标题】：Understanding JSF as a MVC framework将 JSF 理解为 MVC 框架
【发布时间】：2012-04-24 01:54:42
【问题描述】：

我正在阅读 JSF，我感到很困惑为什么 JSF 是一个 MVC 框架（或至少哪些部分属于哪个“字母”）。

我看了这个问题：What components are MVC in JSF MVC framework?

如果您不在聚合视图中查看它，我会读到那里，模型是您的实体，视图是您的 XHTML 代码，控制器是托管 bean。嗯...好吧，但是视图不是经常依赖于执行进一步的业务逻辑调用，例如返回一组实体，描述是否仍然合适？

我读过的一本书将其描述为托管 bean 是 Faces Servlet（控制器）用来调用业务层（模型）的某种“消息”传递器，然后 XHTML 代码就是视图。

有太多的解释和差异，所以我不知道是哪一个或如何理解它。

【问题讨论】：

标签： java jsf jakarta-ee model-view-controller

【解决方案1】：

以简约的形式，它是：

模型：用于持久性（Hibernate、JPA 等）和数据建模（Java Beans）的任何东西。
查看：xhtml、jsp等
控制器：托管 Bean。

JSF 使您能够控制您的请求/响应。创建模型/视图的方式并不直接连接到框架 MVC 概念。这只是一个选择问题。 MVC 概念与代码组织有关。

类似地，Struts 是一个 MVC 框架，但它主要用作控制器。

我想我可以帮助您更好地阐明您的想法。

【讨论】：

Java Bean 和托管 Bean 有什么区别？
嗨@KorayTugay Java Beans 是带有getter 和setter 以及默认构造函数的简单类，而Managed Bean 是一个轻量级的容器管理对象。 Java Bean：en.wikipedia.org/wiki/JavaBean/index.html 托管 Bean：docs.oracle.com/javaee/6/tutorial/doc/gjaam.html#gjacb
谢谢，上面的回答大胆地指出托管 bean 不是控制器。所以这真的有点令人困惑。
如果可能的话，你能用简单的英语解释一下“用于持久性”是什么意思吗？
假设您将使用持久层，然后您应该定义自己的模型类，无论它是什么（ORM 解决方案甚至 JDBC）。假设您选择了 JDBC，并且您将拥有像“Person.java”这样的类，例如具有名称和年龄作为属性。在坚持之前，您必须设置它的值（名称、年龄等）。这通常被称为通用的“实体”或模型。如果您选择像 (Hibernate) 这样的 ORM 解决方案，您应该使用注释 (@Entity) 或 XML 文件映射您的类。希望你明白，这肯定是一个相当肤浅的解释。

【解决方案2】：

在 JSF 和许多其他 Web 框架中通常不完全清楚它的哪些部分对应于 MVC 的哪个部分的部分原因是 MVC 模式最初是为桌面应用程序设计的。

在桌面应用程序中，节点 M、V 和 C 是最大连通图，这意味着每个部分都可以与其他每个部分进行通信。例如。如果模型发生更改，它可以将此更改推送到视图。这在桌面应用程序中有多个视图表示的情况下尤其明显。换一个，实时查看另一个更新。

由于 Web 应用程序的客户端/服务器和请求/响应性质，经典 MVC 不会 1:1 映射到大多数 Web 框架。

具体来说，JSF中的映射如下：

模型 - 服务/DAO 以及它们生产和消费的实体。入口点是托管 bean，但在 Java EE（JSF 是其中的一部分）中，这些工件通常分别由 EJB 和 JPA 实现。
视图 - 将 UI 组件及其组合成一个完整的页面。这完全属于 JSF 领域，分别由 JSF UIComponents 和 Facelets 实现。
控制器 - 处理来自用户的命令和传入数据的交通警察，将其路由到正确的部分并选择要显示的视图。在 JSF 中没有编写此控制器，但它已经由框架提供（它是 FacesServlet）。

尤其是最后一部分通常不太好理解：在 JSF 中，您不实现控制器。因此，支持 bean 或任何其他类型的托管 bean 不是控制器。

第一部分（模型）也并不总是很清楚。业务逻辑可以由 EJB 和 JPA 实现，但从 JSF 的角度来看，值绑定所引用的一切都是模型。这也是 JSF 生命周期阶段之一的名称的来源：Update Model。在这个阶段，JSF 将数据从 UI 组件推送到模型中。从这个意义上说，（JSF）托管 bean 就是模型。

虽然 JSF 本身并没有明确定义这个概念，但托管 bean 有一个经常重复使用的特定用法，称为 backing bean。

对于 JSF，支持 bean 仍然是模型，但实际上它是位于模型、视图和控制器中间的管道元素。因为它执行一些可能被视为一些控制器任务的任务，所以这经常被误认为是控制器。但是，如前所述，这是不正确的。它还可以执行一些模型任务，偶尔也可以执行一些视图逻辑。

另见：

【讨论】：

采用这种方法，在 Spring MVC 中，控制器（或前端控制器）是 DispatcherServlet，而 Spring 控制器是模型的一部分。听起来很奇怪：S
作为一个管道组件，支持 bean 通常被注入一个服务，它从中获取一个或多个实体。这些实体确实被抓住了。通过吸气剂返回整个实体。视图组件绑定到实体的各个属性。基本上，支持 bean 意味着服务代码保持“纯”，并且数据在 bean 范围内缓存（通常是视图范围或请求范围）。
@RodmarConde 好吧，也许有点，但在这种情况下，一些客户端代码通常被视为视图，而 Web 服务只是通往服务的路径。
@ArjanTijms 你给出的答案就像一个爆头，很容易得到准确的点。
您提供的链接已失效：sts.tu-harburg.de/pw-and-m-theses/2007/maab07.pdf

【解决方案3】：

托管 bean 思想的有趣之处在于它既可以用作模型（MVC 模式）也可以用作控制器（mediating-controller MVC pattern，也称为模型视图适配器），其中模型和视图不直接互动。

在后一种情况下，路由机制不是控制器，因为业务逻辑包含在托管 bean 中，而模型是严格的域模型。然后我们有：

Model - 包含域模型，在大多数情况下代表数据库中的表，通过 DAO 持久化。
View - 连接到 bean 的 ui 组件；
Controller - 包含业务逻辑并处理视图和模型之间通信的托管 bean。

我认为有些人将 mediating-controller MVC 与普通 MVC 混淆了，这导致遇到的解释不同。

【讨论】：

【解决方案4】：

我认为，这里的所有回答者都是正确的。但对我来说，混淆的主要点在于将来自框架（此处为 JSF）的 mvc 组件定义与您在应用程序设计中定义的模型和控制器组件混合：

假设您在业务应用程序中从 JSF 更改为任何其他 Web UI 框架：你仍然会有一个“商业模式”和一个“商业控制者”。（在我们的项目中，我们只是将这些组件称为“模型”和“过程”。）这意味着什么：要么您不能使用 mvc 来描述整个应用程序架构，而只能用于 UI，或者您可能必须在整个应用程序堆栈中接受许多控制器、模型之类的组件。

【讨论】：