我正在使用的项目使用 JSF + Spring + Hibernate。
这是我经常困惑的一个设计问题。
我目前继承了一个包含 dao -> 服务 -> 视图 -> 控制器“分层”方法的项目。
“控制器”层/层？目前拥有与前端交互的所有逻辑和对象。有人告诉我，最好将其分为两层/层，其中“控制器”层/层仅包含与前端交互的方法/对象，第二层（bm？）包含所有业务逻辑由控制器使用。
1st.) 以这种方式划分控制器的目的是什么？
2nd.) 让它保持现在的样子有什么问题吗？
问问题
3265 次
3 回答
5
1st.) What would the purpose be of dividing up the controller in such a way?
您必须处理Service Layer. 将业务实体从以下方面分离的好处Controller/UI Layer：
- 您可以将业务实体与其他客户端部分重用。示例：如果您正在开发基于 Web 的应用程序作为 UI，那么稍后您还开发了桌面 UI。
Business Layer在这种情况下，您可以使用多个 UI重用您的操作。您还可以将业务层用作 Web 服务。 - 解耦的业务操作更易于管理。如果开发团队中的某个人不知道 UI 代码是如何工作的，并且只想更正一些业务逻辑，他可以做到。
2nd.) Is there anything wrong with leaving it the way it currently is?
如果您不熟悉分层架构，则需要一些时间来理解和实现所需的层。这取决于时间框架和应用程序要求。如果您打算在应用程序中使用上述几点，请使用分层架构，否则请使用当前实现。
于 2012-08-18T05:20:24.660 回答
2
如果您问为什么拥有视图使用的服务层是个好主意，那么答案是您通常希望从与特定视图不同的应用程序部分访问服务。
例如，假设您有验证订单的逻辑，该订单最初主要用于某些 /order.xhtml 页面。将服务和相应的对象（比如订单）放在视图中不会损害该页面。
但是随后需要从批处理作业中进行订单验证。如果用于验证的代码与您的视图紧密耦合，这将是不可能的或非常困难的，并且很可能非常尴尬（我见过有人嘲笑 JSP PageContext，因为某些业务逻辑碰巧需要它）。
还有很多其他情况会出现这种情况，例如通过 JAX-RS 的外部 API、完全不同的视图（另一个用户的页面，或者可能是移动目标 UI）等。
于 2012-08-17T22:30:48.563 回答
0
业务逻辑层不应在服务层上实现。
DAO/服务层 -> 业务逻辑层 -> UI 控制器
-rico
于 2013-11-28T11:40:27.190 回答