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术语）调用，服务本身将调用DAO的必要时使用JPA。
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 for User ， ProductService for 产品， OrderService 订单等等。你绝对不应该有一个巨大的服务大一点左右。这是极端紧密耦合。
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）在诸如Tomcat之类的准系统servlet容器中不可用。您需要在其上安装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依赖项。因此，服务层代码中的任何（in）直接导入 javax.faces。* 表示设计错误。您应该将特定代码行保留在辅助bean中（通常是根据服务调用结果添加faces消息的代码）。这样，服务层可以重用于其他前端，例如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操作之一中发生异常，那么完整回滚将是触发。这样，您最终得到一个干净的DB状态而不是脏DB状态，因为例如第一个DB操作查询成功，但第二个没有。
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.
- 为实体创建主详细信息页面，如何链接它们以及选择哪个bean范围
- < a href =https://stackoverflow.com/questions/18369356/when-is-it-necessary-or-convenient-to-use-springjsf2-or-ejb3jsf2-or-all-of-the/>何时是是否必须或方便地将Spring或EJB3或所有这些一起使用？
- JSF控制器，服务和DAO
- Creating master-detail pages for entities, how to link them and which bean scope to choose
- When is it necessary or convenient to use Spring or EJB3 or all of them together?
- JSF Controller, Service and DAO
这篇关于JSF服务层的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
