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

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

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

где вы обычно размещаете эти DTOs? Наряду с объектами домена, т. е. в том же пространстве имен?

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

    public class MedicalGroupDTO
    {
        //...
    }
}
7
oop

4 ответов

  • DTO предоставляют слой абстракции для вашей модели домена. Поэтому вы можете изменить модель и не нарушать контракт, который у вас есть для клиентов службы. Это сродни обычной практике проектирования баз данных, когда представления и процедуры становятся уровнем абстракции для базовой модели данных.
  • сериализация-вы можете предоставлять данные и отправлять раздутые сообщения по проводу. Это может быть смягчено с помощью атрибутов сериализации, но у вас все еще может быть дополнительная информация.
  • неявные и явные контракты-предоставляя объекты домена, вы предоставляете клиенту интерпретировать их использование, поскольку у них нет полной модели в их распоряжении. Часто обновления объектов домена выполняются неявно на основе наличия или удаления ассоциаций или слепо принимают все изменения. DTOs явно выражают использование сервиса и требуемую операцию.
  • отключенные сценарии - наличие явных сообщений или DTOs было бы проще реализовать обмен сообщениями и шаблоны обмена сообщениями, такие как Message Broker и т. д.
  • DDD-pure DDD требует, чтобы объекты домена были внешне неизменяемыми, и поэтому вы должны выгрузить это на другой объект, обычно DTO.
7

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

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

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

4

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

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

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

3

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

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

1