我不确定我在 JSF 中使用 MVC 环境的方法是否是最好的方法。由于我试图充分利用 JSF，我想知道我的服务层(或模型，用 MVC 术语来说)应该如何“设计”。
我知道 View-Controller 比率应该是 1 比 1(排除了异常(exception)情况)。 现在我应该以什么方式设计我的服务层？我应该使用一项大服务(不这么认为)吗？如果不是，我应该根据什么拆分我的服务？
请注意，我的服务将从 Bean(MVC 术语中的 Controller )调用，并且服务本身将在必要时使用 JPA 调用 DAO。
提前致谢
最佳答案
服务层(业务模型)应围绕主要实体(数据模型)设计。例如。 UserService 用于 User，ProductService 用于 Product，OrderService 用于 Order 等。您绝对不应该拥有一个庞大的服务类左右。这是极其紧密的耦合。
对于服务层 API 本身，Java EE 6 提供 EJB 3.1 作为服务层 API。在黑暗的 J2EE 时代，很久以前，当 EJB 2.0 难以开发时，Spring 更多地被用作服务层 API。现在有些人仍在使用它，但由于 Java EE 6 已经整合了从 Spring 中学到的所有优秀经验，它已成为 superfluous .请注意，EJB(和 JPA)在 Tomcat 等准系统 servlet 容器中不可用。您需要在其上安装例如 OpenEJB(或仅升级到 TomEE)。
无论选择何种服务层 API，最好的办法是通过完全在服务层中执行业务工作来保持您的 JSF 支持 bean( Action )监听器方法尽可能流畅。请注意，服务层本身应该不有任何 JSF 依赖项。因此，服务层代码中 javax.faces.* 的任何(内)直接导入都表明设计不佳。您应该将特定的代码行保留在支持 bean 中(通常是根据服务调用结果添加面孔消息的代码)。通过这种方式，服务层可重用于其他前端，例如 JAX-RS 甚至普通 servlet。
您应该了解，Java EE 应用程序中服务层的主要优势是容器管理事务的可用性。 @Stateless EJB 上的一个服务方法调用实际上算作单个 DB 事务。因此，如果在使用服务方法调用调用的 @PersistenceContext EntityManager 的任何 DAO 操作之一期间发生异常，则将触发 complete 回滚。这样，您最终会得到一个干净的 DB 状态而不是一个脏 DB 状态，因为例如第一个 DB 操作查询成功，但第二个没有。
另见:
关于java - JSF 服务层，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13011392/