JSF 服务层 [英] JSF Service Layer
问题描述
我不确定我在 JSF 中使用 MVC 环境的方法是否是最好的方法.由于我试图充分利用 JSF，我想知道我的服务层(或模型，用 MVC 术语来说)应该如何设计".
I am not sure whether my approach with the MVC environment in JSF is the best way to go. Since I am trying to get the most out of JSF I would like to know how my Service Layer (or Model, speaking in MVC terms) should be 'designed'.
我知道 View-Controller 比率应该是 1 比 1(排除例外).现在我应该以什么方式设计我的服务层?我应该使用一项大型服务吗(不这么认为)?如果不是，我应该根据什么来拆分我的服务?
I know the View-Controller ratio should be 1 to 1 (exceptions ruled out). Now in what way should I design my Service Layer? Should I use one big service (don't think so)? If not, based on what should I split my services?
注意，我的服务将从 Beans(MVC 术语中的控制器)调用，并且服务本身将在必要时使用 JPA 调用 DAO.
Note, my Service will be called from the Beans (Controllers in MVC terms) and the Service itself will call DAO's using JPA when necessary.
提前致谢
推荐答案
服务层(业务模型)应该围绕主要实体(数据模型)进行设计.例如.UserService 用于User，ProductService 用于Product，OrderService 用于Order 等.你绝对不应该有一个巨大的服务类.这是极其紧密的耦合.
The service layer (the business model) should be designed around the main entity (the data model). E.g. UserService for User, ProductService for Product, OrderService for Order, etc. You should absolutely not have one huge service class or so. That's extreme tight coupling.
至于服务层 API 本身，Java EE 6 提供 EJB 3.1 作为服务层 API.在黑暗的 J2EE 时代，很久以前当 EJB 2.0 很难开发时，Spring 更常被用作服务层 API.现在有些人仍在使用它，但由于 Java EE 6 已经整合了从 Spring 中学到的所有优秀课程，它已成为 多余.请注意，EJB(和 JPA)在准系统 servlet 容器(例如 Tomcat)中不可用.例如，您需要在其上安装 OpenEJB(或仅升级到 TomEE).
As to the service layer API itself, Java EE 6 offers EJB 3.1 as service layer API. In the dark J2EE ages, long time ago when EJB 2.0 was terrible to develop with, Spring was more often been used as service layer API. Some still use it nowadays, but since Java EE 6 has incorporated all the nice lessons learnt from Spring, it has become superfluous. Note that EJB (and JPA) is not available in barebones servletcontainers such as Tomcat. You'd need to install for example OpenEJB on top of it (or just upgrade to TomEE).
无论选择哪种服务层 API，最好的方法是通过完全在服务层中执行业务工作来保持您的 JSF 支持 bean(操作)侦听器方法尽可能灵活.请注意，服务层本身应该不具有任何 JSF 依赖项.因此，服务层代码中 javax.faces.* 的任何(in)直接导入都表明设计不佳.您应该在支持 bean 中保留特定的代码行(它通常是根据服务调用结果添加人脸消息的代码).通过这种方式，服务层可重用于其他前端，例如 JAX-RS 甚至普通 servlet.
Regardless of the service layer API choice, best would be to keep your JSF backing bean (action)listener methods as slick as possible by performing the business job entirely in the service layer. Note that the service layer should by itself not have any JSF dependencies. So any (in)direct imports of javax.faces.* in the service layer code indicates bad design. You should keep the particular code lines in the backing bean (it's usually code which adds a faces message depending on the service call result). This way the service layer is reuseable for other front ends, such as JAX-RS or even plain servlets.
您应该明白，Java EE 应用程序中服务层的主要优势是容器管理事务的可用性.@Stateless EJB 上的一个服务方法调用有效地算作单个数据库事务.因此，如果在使用由服务方法调用调用的 @PersistenceContext EntityManager 的任何 DAO 操作之一期间发生异常，则将触发 complete 回滚.这样你最终会得到一个干净的数据库状态而不是一个脏的数据库状态，因为例如第一个数据库操作查询成功了，但第二个没有.
You should understand that the main advantage of the service layer in a Java EE application is the availability of container managed transactions. One service method call on a @Stateless EJB counts effectively as a single DB transaction. So if an exception occurs during one of any DAO operations using @PersistenceContext EntityManager which is invoked by the service method call, then a complete rollback will be triggered. This way you end up with a clean DB state instead of a dirty DB state because for example the first DB manipulation query succeeded, but the second not.
这篇关于JSF 服务层的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
