Добавление поведения к объекту DTO

Question

Это вопрос дизайна, который меня смущает.

Как вы знаете, объект состоит из атрибутов и поведения. В веб-программировании я реализовал несколько объектов протокола как 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(); 
    } 

} 

Итак, как вы можете видеть, я хочу дать запрос классы отвечают за выполнение всего, о чем они просят.

Мой вопрос: хороший дизайн? Правильно ли предоставлять объектам DTO обязанности выполнять то, для чего они предназначены? Или объекты DTO предназначены только для передачи данных?

PS: В этом дизайне возникает проблема, которая требует применения некоторых внешних ссылок на некоторые другие объекты, такие как службы, dao и т. Д. Итак, какой элегантный способ вставить эти зависимости в эти экземпляры?

Answer 1

Обычно DTO не имеют логики (или очень простой логики преобразования, например, возвращения возраста человека с даты рождения).

Вы можете использовать шаблон, который у вас есть ... определенно, это просто объекты, которые не являются DTO, но более богатыми объектами (обычно это хорошо). Вы не добавляете суффикс DTO для имен классов, поэтому я бы сказал, что все в порядке, потому что объект Request может иметь какое-то поведение.

Редактировать

Я вижу, что вы пытаетесь сделать. Это можно сделать с помощью Dependency Injection + AOP, но я думаю, что есть другие шаблоны, которые могут иметь более четкое различие и намного меньше черной магии.

С помощью подхода, который вы хотите использовать, ваш Request является точкой входа в ваше приложение (к ядру вашего домена) и представляет собой вариант использования, который вы хотите запустить.

Подход, который я обычно использую, основанный на Domain-Driven Design (DDD) и гексагональной архитектуре, должен иметь DTO, которые могут быть привязкой к транспортной технологии (например, аннотации xml/json). И я использую слой Application Services, который служит фасад в логике домена. Application Service просто отвечает за оркестровку, а не за бизнес-логику.

В рамках оркестровки Application Service должен получить ссылку на объект, который имеет бизнес-логику. В DDD эти объекты обычно Aggregates.

Я думаю, что я бы написал намного больше об этом, но уже есть немало действительно хороших ресурсов, объясняющих, как создавать хорошие приложения, а объяснение там лучше, чем то, что я могу здесь сделать :).

Если вас это интересует, и не прочь потратить немного больше времени (и, возможно, несколько долларов). I strong предлагаем вам получить копию Growing Object-Oriented Software и Implementing Domain-Driven Design. Оба отличные книги, очень легко читаемые, и, к счастью, все примеры на Java.