Какой смысл в объекте передачи данных (DTO)?

Question

Почему я должен использовать объекты DTO / Domain, когда я могу просто поместить все бизнес-классы в библиотеку классов, использовать их в бизнес-логике, а затем передать те же бизнес-объекты граничным классам?

UPDATE: Все замечательные моменты, спасибо за помощь. Следующий вопрос:

Где вы обычно размещаете эти DTO? Рядом с объектами Домена, т. Е. В том же пространстве имен?

namespace MedSched.Medical
{
    public class MedicalGroup
    {
        //...
    }

    public class MedicalGroupDTO
    {
        //...
    }
}

Answer 1

• DTO предоставляют уровень абстракции для вашей доменной модели. Таким образом, вы можете изменить модель и не расторгать договор на обслуживание клиентов. Это похоже на обычную практику проектирования баз данных, когда представления и процедуры становятся уровнем абстракции для базовой модели данных.
• Сериализация - вы можете переэкспонировать данные и отправлять раздутые сообщения по сети. Это может быть смягчено с помощью атрибутов сериализации, но у вас все еще может быть дополнительная информация.
• Неявные и явные контракты - выставляя доменные объекты, вы оставляете за клиентом возможность интерпретировать их использование, поскольку в их распоряжении нет полной модели. Вы часто будете вносить обновления в доменные объекты неявно, основываясь на наличии или удалении ассоциаций, или слепо принимать все изменения. DTO явно выражают использование сервиса и желаемую операцию.
• Отключенные сценарии - наличие явных сообщений или DTO упрощает реализацию шаблонов обмена сообщениями и сообщений, таких как Message Broker и т. Д.
• DDD - чистый DDD требует, чтобы доменные объекты были неизменными извне, и поэтому вы должны перенести это на другой объект, обычно DTO.

Answer 2

Я могу представить 2 основных сценария использования DTO:

• Вы создаете свой бизнес-объект из данных, которые являются неполными и не пройдут проверку. Например, вы анализируете файл CSV или файл Excel, из которого создается ваш бизнес-объект. Если вы используете данные непосредственно из этих объектов для создания своего бизнес-объекта, вполне возможно потерпеть неудачу в нескольких правилах проверки внутри объекта, поскольку данные из таких файлов подвержены ошибкам. Они также имеют тенденцию иметь другую структуру, которая есть у вас в конечном бизнес-объекте: будет полезно иметь заполнитель для этих неполных данных.

• Вы транспортируете свой бизнес-объект через среду с интенсивным использованием полосы пропускания . Если вы используете веб-сервис, вам нужно будет использовать DTO для упрощения вашего объекта перед транспортировкой; в противном случае CLR будет трудно сериализовать все ваши данные.

Answer 3

DTO - это объекты передачи данных, ключевым словом является Transfer. Они хороши, когда вы хотите передать свои объекты по проводам и потенциально общаться с другим языком, потому что они «легковесны» (т.е. не имеют бизнес-логики.)

Если ваше приложение не основано на веб-сервисах, DTO на самом деле ничего не купят.

Поэтому решение использовать или не использовать DTO должно основываться на архитектуре вашего приложения.

Answer 4

Бывают случаи, когда данные , которые вы хотите передать, не соответствуют точно структуре бизнес-объектов, и в этом случае вы используете DTO.

Пример: когда вы хотите передать подмножество данных или проекции.