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 回答