4

理想情况下，Spring MVC 应用程序中的控制器必须接收请求，将请求发送到 API，将（调用的）结果加载到模型（以便视图随后呈现它）并转发到视图。他们不应该再做。

我的控制器今天做的远不止这些，我想将某些职责从控制器转移到其他 API。我今天的应用程序设计（非常典型）：

controller <-> Service API <-> DAO <-> DB

今天，控制器填补了 Web 应用程序需要的内容和服务 API 提供的内容之间的差异。我想在控制器和服务 API 之间放置额外的层/层，以消除这个增量。我的问题是这些应该是什么层，这些新层的职责应该是什么？

我目前的想法如下

controller <-> controller helper <-> Business API <-> Service API <-> DAO <-> DB

控制器助手（Web 上下文感知 - 将依赖于 Model、HttpServlet 和其他 Web 上下文类）：

  1. 将实体转换为 DTO 对象（2 种方式）
  2. 将 ID 解析为实体。例如，控制器查找学生 ID（使用密钥）并将其转换为学生实体。

业务 API（无 Web 上下文依赖 - 可以进行 JUnit 测试）：

  1. 充当门面。调用多个服务 API 来实现一个业务请求。
  2. 提供专门为 Web 应用程序定制的 API。

你会用不同的方式解决这个问题吗？是否有与此特定问题相关的任何资源（书籍、文章等）？

之前的一些讨论没有回答我的问题：

设计mvc控制器层

服务层 = 应用层 = GRASP 控制器层

将验证、Html 助手移动到 MVC 中的服务层

谢谢，维杰

4

2 回答 2

1

服务包含应用程序的一般业务逻辑。它们几乎是控制器和 DAO/DB 之间的任何东西。

您的“业务层”和“控制器助手”只是更多的服务。为了简单起见，我会保留经典设计：

Controllers <-> possible Services <-> possible DAOs <-> DB

如果我有很多服务（我通常不会）碰巧执行相同类型的逻辑，我自然会将它们拆分为子包。例如 ：

  • services.facade 或 services.business
  • services.adapter 用于 DTO（除非您使用简单的类来完成这项工作）

外观服务由控制器调用，如下所示：someFacade.someMethod(SomeDTO someDto)。然后外观处理 DTO <-> 实体转换，这要归功于其他服务（或简单的类）。

这就是我在你的情况下会做的事情。在一个理想的世界中（没有遗留系统，或者在一个从头开始的项目中），我会直接使用实体作为表单对象（而不是 DTO），并且我的大部分服务都是门面（如果可能的话，其余的都是简单的类）。

于 2012-09-24T21:24:34.523 回答
0

我是 Spring MVC 的新手，也面临着这个困境。尽管 Spring 对我来说是新事物，但我已经使用 MVC 工作了好几年了。我同意控制器应该只接受请求、分派它们并以正确的格式呈现结果。我认为服务不一定是帮助抽象存在的最佳场所。我相信一个服务应该封装一个特定的 API 并且什么都不做。我觉得创建许多“类型”的服务会使这种模式复杂化，并不清楚责任落在哪里。

我相信帮助者更适合作为服务的兄弟姐妹；它们应该用@Component 而不是@Service 装饰。它们的作用是充当底层 API 的外观，这些 API 需要在通过端点公开的模型上转换状态。Controller->Helper->[Services] 模式促进了关注点的清晰分离、代码可重用性和高度可测试性。这种模式的本质是防止控制器膨胀，所以你最终会得到超薄的控制器，它实际上只做分派请求和呈现响应。

于 2013-12-19T20:59:15.253 回答