Java EE最佳设计方法。业务逻辑层？

Question

我正在使用的项目使用JSF + Spring + Hibernate。

这是一个我经常被混淆的设计问题。

我目前继承了一个包含dao的项目 - ＆gt;服务 - ＆gt;查看 - ＆gt;控制器“分层”的方法。

“控制器”层/层？目前拥有与前端交互的所有逻辑和对象。有人告诉我，最好将分开分成两层/层，其中“Controller”层/层只包含与前端和第二层交互的方法/对象（bm） ？）包含 控制器使用的所有业务逻辑。

1st。）以这种方式划分控制器的目的是什么？

第二。）离开目前的方式有什么不妥吗？

Answer 1

1st.) What would the purpose be of dividing up the controller in such a way?

您必须处理Service Layer中的业务逻辑。将业务实体与Controller/UI Layer分开的好处：

1. 您可以将业务实体与其他客户端部分一起使用。示例：如果您正在开发基于Web的应用程序作为UI，稍后您还开发了桌面UI。在这种情况下，您可以重复使用多个UI的Business Layer操作。您还可以使用业务层作为Web服务。
2. 分离的业务运营更易于管理。如果开发团队的某个人不知道UI代码是如何工作的，并且只想纠正某些业务逻辑，他就可以做到。

2nd.) Is there anything wrong with leaving it the way it currently is?

如果您不熟悉分层架构，则需要一些时间来理解和实现所需的层。这取决于时间范围和应用要求。如果您计划在应用程序中使用上述要点，请使用分层体系结构，否则请使用当前实现。

Answer 2

如果您问为什么拥有视图使用的服务层是个好主意，那么答案是，您通常希望从应用程序中与特定视图不同的部分访问服务

例如，假设您有逻辑来验证订单，该订单最初主要用于某些/order.xhtml页面。在视图中将服务和相应的对象（比如Order）放在那个页面上也不会有什么坏处。

但随后要求从批处理作业进行订单验证。如果该验证的代码与您的视图紧密耦合，那么这将是不可能或非常困难的，并且很可能非常尴尬（我见过人们嘲笑JSP PageContext，因为某些业务逻辑恰好需要它）。

还有一些其他情况会逐渐增加，例如通过JAX-RS的外部API，一个完全不同的视图（另一个用户的页面，或者可能是移动目标UI）等。

Answer 3

不应在服务层上实现业务逻辑层。

DAO /服务层 - ＆gt;业务逻辑层 - ＆gt; UI控制器

-rico