DTO = Объект передачи данных, как звучит.Объект, который передает данные между системными слоями.Цель часто состоит в том, чтобы адаптировать данные запроса и ответа так, чтобы они соответствовали сценарию использования.Примером может быть то, что вы запрашиваете резюме через CandidateService системы управления персоналом на прикладном уровне.Служба кандидатов загружает информацию, которая охватывает различные доменные объекты: WorkExperince, Education, Personal Letter и т. Д. Чтобы избежать сложного и массивного графа объекта ответа, мы можем сгладить ответ, построив объект DTO, который точно соответствует тому, для чего клиент (GUI)необходимо.
Многое можно сказать о DTO.Но я не хочу писать роман :) Но DTO не принадлежат ни к модели предметной области, ни к ядру.DTO чаще всего упоминается в DDD как инструмент для связи между службами приложений для клиентов, особенно если вы используете веб-службы (WCF и т. Д.).Тогда DTO - это идеальный способ сериализации части вашего домена в сообщение веб-службы (сериализованный DTO).
Надеемся, вы также можете спросить своих коллег / коллег, что они намеревались достичь с помощью DTO.У DTO есть несколько недостатков, обычно это дает вам дополнительный уровень, а это означает, что нужно делать больше на этапе технического обслуживания ...
(к настоящему времени почти новинка). Я использую DTO только тогда, когда есть реальная выгода итогда вы можете доставлять сложные ответы с помощью DTO, точно соответствующие потребностям клиентов.В противном случае клиенту обычно необходимо вызывать различные службы или методы для сбора достаточного количества информации.