Java JSF服务层

我不确定我在JSF中使用MVC环境的方法是否是最好的方法。由于我试图充分利用JSF，我想知道我的服务层（或模型，用MVC术语来说）应该如何“设计”

我知道视图控制器的比例应该是1:1（排除了例外情况）。 现在，我应该以什么方式设计我的服务层？我应该使用一个大服务吗（我不这么认为）？如果没有，我应该根据什么划分我的服务

注意，我的服务将从bean（MVC术语中的控制器）调用，并且服务本身将在必要时使用JPA调用DAO

提前感谢

服务层（业务模型）应该围绕主实体（数据模型）进行设计。例如，

UserService

用于

User

，

ProductService

用于

Product

，

OrderService

用于

Order

，等等。你绝对不应该有一个庞大的服务类别。这是非常紧密的耦合

至于服务层API本身，JavaEE6提供EJB3.1作为服务层API。在黑暗的J2EE时代，很久以前，EJB2.0的开发非常糟糕，Spring更多地被用作服务层API。现在仍有一些人在使用它，但由于JavaEE6吸收了从Spring中学到的所有好的经验教训，它已经变得非常有用了。请注意，EJB（和JPA）在诸如Tomcat之类的基本servletcontainers中不可用。例如，您需要在其上安装OpenEJB（或者升级到TomEE）

不管服务层API的选择如何，最好的方法是通过完全在服务层执行业务作业来保持JSF支持bean（action）侦听器方法尽可能流畅。请注意，服务层本身不应该有任何JSF依赖项。因此，在服务层代码中直接导入

javax.faces.*

表示设计不好。您应该在backingbean中保留特定的代码行（通常是根据服务调用结果添加faces消息的代码）。通过这种方式，服务层可重用于其他前端，例如JAX-RS甚至普通servlet

---

您应该了解，JavaEE应用程序中服务层的主要优势是容器管理事务的可用性。

@无状态

EJB上的一个服务方法调用有效地算作单个DB事务。因此，如果在使用由服务方法调用的

@PersistenceContext EntityManager

的任何DAO操作期间发生异常，则将触发完全回滚。这样，您将得到一个干净的DB状态，而不是脏DB状态，因为例如，第一个DB操作查询成功了，但第二个没有成功

另见：

---

如果你的应用程序中只有很少的实体，那么服务和模型实体之间的1:1比例可能还不错。但是如果它是一个大的应用程序，就会有太多的服务

服务的数量取决于您正在设计的应用程序的用例。一旦在分析阶段确定了它们，就必须根据它们的功能将它们分组。每组用例将是一个服务，每个用例将是该服务中的一个方法。每个服务都可以管理多个模型实体（您必须向其中注入执行其功能所需的DAO）。通常，服务的用例管理模型的类图中相互关联的实体。这些服务可能遵循“最大内聚/最小耦合”的良好实践

DAO和模型实体之间的比率为1:1。每个DAO对其实体执行CRUD操作和查询。如果一个方法需要查询2个相关实体，则根据业务概念将其放入更合适的DAO中

在JSF表示层中，我的页面和控制器之间的比例都不是1:1，这对控制器来说太多了。我将执行每个服务的用例所需的所有页面分组到一个控制器中。因此，控制器和服务之间的比率为1:1，将每个服务注入到其页面执行其用例的控制器中

当然，这些是一般原则。应用程序中可能有一些特定的案例破坏了它们，但它们很少

---

您可能没有太多的服务和控制器，但也不会太少，因为这样它们就会有太多的逻辑和字段。你必须达成妥协。

所以。。如果将服务与DAO（以及实体）进行比较，服务的比率将为1:1？剩下的解释是100%清楚的，我的服务的目的已经确定了（所以业务逻辑，没有JPA逻辑，没有JSF逻辑）。我还需要进一步研究正确的范围等等。再次感谢：）不完全是1:1。您可以在一个服务类中注入多个DAO。取决于实体本身是否有任何子实体。@BalusC将一个hibernate类声明为JSFbean是否常见？例如，我有一个公司视图（它有属性名称、地址、联系人等）。我有一个问题，因为除了所有的公司财产，我还有一个清单。它给了我一个错误，因为它是一个hibernate类，所以它试图找到一个类型为List的列，但该列不存在。我可以通过使问题暂时化来解决它。但是这是一个好的实践吗？@Erick：查看“另请参阅”链接，了解在支持bean类中正确使用实体类和服务类的具体示例。您应该了解Java EE应用程序中服务层的主要优势是容器管理事务的可用性。我喜欢这个