4

我一直在考虑这个问题，但还没有提出如何在 JSF 项目中为表示层组织我的 bean/类的最佳实践。显然有很多因素在起作用，但我想讨论一下。以下是我目前的思路：

考虑一个包含视图页面（查看数据）和编辑页面（添加、更新、删除数据）的基本 JSF（不幸的是，仍然停留在 JSF 1.xx 上）。这是我组织项目的方式：

请求范围内的 BackingBean：

  • 查看相关内容（保存状态、渲染逻辑等）。仅在一个请求中需要的东西
  • 动作、动作侦听器和值更改侦听器。如果它们适用于多个视图，则可以将它们分离到自己的文件中。

会话范围的 BackingBean：

  • 任何需要保留比一个请求更长的东西。数据库数据、SelectItems 等。
  • 此 bean 被注入到请求 bean 中，并存储任何数据对象的实例

数据对象：

  • 把数据对象做成bean似乎没有意义，所以分开存放。这将是诸如用户、书籍、汽车之类的东西，您将在页面上显示的任何对象。该对象还可以包含视图辅助方法，例如 getFormattedName() 等。

道：

  • 处理与业务逻辑层的所有交互的非 bean 对象。它加载数据bean并准备提交等。我通常将其设为公共静态方法类。

转换器、验证器：

  • 单独的文件

这似乎是您的普通 JSF 应用程序所需的全部内容。我已经阅读了这个： http: //java.dzone.com/articles/making-distinctions-between，以及这里的回复：JSF backing bean structure (best practice)，但我从来没有觉得我们有一个完整的画面。BalusC 的回复很有帮助，但似乎并没有完全涵盖完整的应用程序。让我知道你的想法！

4

1 回答 1

1

我认为您通常走在正确的轨道上，但是我会做一些不同的事情：

  1. 我会将您的 DAO 层拆分为两个单独的层，一个纯 DAO 层仅负责从各种来源（例如数据库调用、Web 服务调用、文件读取等）获取数据。然后，我将拥有一个业务逻辑层，其中包含对 DAO 调用的传递以及任何其他计算、算法或其他不特定于任何 JSF 视图的通用业务逻辑。

  2. 在 MVC 模式中，您的 ManagedBean 扮演控制器的角色，因此也应该是表示逻辑（特定于操作视图或各种视图组件之间交互的逻辑）的存储库。它还将您的业务逻辑与事件行为联系起来。

  3. 我不会为您的业务逻辑或 DAO 层使用公共静态方法。这不适合自动化单元测试，并且会阻止您的应用程序使用 CDI 或 Spring 等依赖注入框架。而是为您的 BO 和 DAO 创建一个接口，然后为此创建一个实现类。

  4. 关于这一点，请使用 CDI 或 Spring 之类的依赖注入框架 :) 它将允许您自动将业务逻辑对象或 DAO 注入到您的 ManagedBeans 以及您的单元测试中。它还允许您交换实现或 DAO，而无需与应用程序的其他层中的代码进行任何耦合。

于 2012-09-13T17:25:06.543 回答