向 DTO 对象添加行为

Question

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

如您所知，对象由属性和行为组成。在 Web 编程中，我已经实现了几个协议对象作为 DTO。这些就像：

abstract AbstractRequest{

   public abstract AbstractResponse apply();
...
}

MathLessonRequest extends AbstractRequest{

    public AbstractResponse apply(){
          ..do something based on request
    }
...
}

HistoryLessonRequest extends AbstractRequest{
    public AbstractResponse apply(){
          ..do something based on request
    }
}

而我想做的是，在我的控制器中，我只想做这样的事情：

@RestController
class SchoolRequestController{

    @RequestMapping(value="/",method = RequestMethod.POST, produces = "application/json")
    @ResponseStatus(HttpStatus.OK)
    @ResponseBody
    public AbstractResponse query(AbstractRequest request){

          return request.apply();
    }

}

所以，正如你所看到的，我想让 Request 类负责执行他们所要求的所有内容。

我的问题是，这是一个好的设计吗？赋予 DTO 对象执行其用途的责任是否正确？还是 DTO 对象仅用于数据传输？

PS：这个设计有一个问题，apply方法需要一些其他对象的外部引用，比如services，dao等。那么将这些依赖注入到这个实例中的优雅方法是什么？

Answer 1

通常 DTO 没有逻辑（或非常简单的转换逻辑，例如从出生日期返回一个人的年龄）。

您可以使用那里的模式...当然，只是对象不是真正的 DTO，而是更丰富的对象（这通常很好）。您没有在类名中添加“DTO”后缀，所以我会说您做得很好，因为 Request 对象可能有一些行为。

编辑

我明白你在做什么。可以使用依赖注入 + AOP，但我认为还有其他模式可能有更清晰的区别和更少的黑魔法。

使用您要使用的方法，您的Request 是您的应用程序（您的域的核心）的入口点，代表您要运行的用例。

我通常使用的方法是基于域驱动设计 (DDD) 和六边形架构，是使用 DTO，它可能会绑定到传输技术（例如 xml/json 注释）。我使用一层Application Services 作为域逻辑的外观。 Application Service 只负责编排，不负责业务逻辑。

作为编排的一部分，Application Service 需要获取对具有业务逻辑的对象的引用。在 DDD 中，这些对象通常是Aggregates。

我想我会写更多关于这方面的内容，但是已经有很多非常好的资源来解释如何设计好的应用程序，而且那里的解释比我在这里能做的要好得多:)。

如果您对此感兴趣，并且不介意多花点时间（也许花几块钱）。我强烈建议您获取Growing Object-Oriented Software 和Implementing Domain-Driven Design 的副本。这两本书都是优秀的书，非常容易阅读，幸运的是所有的例子都是用 Java 编写的。