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

【问题标题】：Java EE best design approach. business logic layer?Java EE 最佳设计方法。业务逻辑层？
【发布时间】：2012-08-17 18:34:35
【问题描述】：

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

这是一个我经常困惑的设计问题。

我目前继承了一个包含 dao -> 服务 -> 视图 -> 控制器“分层”方法的项目。

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

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

2nd.) 保持现在的样子有什么问题吗？

【问题讨论】：

【解决方案1】：

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

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

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

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

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

【讨论】：

【解决方案2】：

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

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

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

还有很多其他情况会出现这种情况，例如通过 JAX-RS 的外部 API、完全不同的视图（另一个用户的页面，或者可能是针对移动设备的 UI）等。

【讨论】：

【解决方案3】：

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

DAO/服务层 -> 业务逻辑层 -> UI 控制器

-里科

【讨论】：