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

DTO соответствует форме данных, которые вы хотите передать. Если это соответствует базовой модели данных, то так тому и быть, но это кстати. В какой-то момент вы можете изменить форму базовой модели данных, но DTO не изменятся.

Кроме того, DTO — это то, что веб-служба передает клиенту. Если ваша модель данных определена на сервере, вы не хотите, чтобы распределенный клиент знал об этой модели данных.

Наконец, ваши классы сущностей могут содержать дополнительную логику, тогда как DTO — это просто свойства, предоставляющие данные, и ничего больше.

Ваше приложение может иметь много концептуальных уровней. Уровень данных, бизнес-уровень, уровень обслуживания, уровень представления и многие другие. Каждый имеет определенную функцию с входом и выходом. Цель состоит в том, чтобы спроектировать слабосвязанную систему (т. е. элементы не сильно зависят друг от друга, поэтому любые изменения изолированы и имеют минимальное влияние). Вы хотите максимизировать ремонтопригодность, улучшить повторное использование и максимизировать скорость. Хитрость заключается в том, чтобы снизить сложность, но создать некоторое базовое разделение, которое позволит вам легко продвигать свой дизайн вперед по мере необходимости. Имейте в виду ЯГНИ! ВАМ ЭТО НЕ НУЖНО! Люди склонны искать и проектировать самые сложные архитектуры для проблем, с которыми они никогда не столкнутся! Сколько раз я слышал: «У нас есть отдельный уровень данных, чтобы мы могли заменить базу данных в будущем»… но я никогда не видел, чтобы это происходило! Работает простой шаблон репозитория.

Согласно предыдущему плакату, у вас есть данные в базе данных (в физической модели), которые вы хотите преобразовать в свое приложение в концептуальную модель. Затем любые клиенты будут использовать вашу концептуальную модель. Я бы сделал это сразу после того, как ваш код приложения извлек данные из базы данных с вашего уровня данных. Это гарантирует, что любые изменения, внесенные в вашу базу данных, будут изолированы от остальной части вашего приложения. Поэтому вам не нужно начинать менять свой пользовательский интерфейс, потому что вы изменили имя поля базы данных. Вам просто нужно обновить свой слой данных.

Если вы выберете Entity Framework в качестве стратегии доступа к данным, она сопоставит вашу базу данных с концептуальной моделью. Если вы конвертируете другие объекты данных из одного типа в другой, обратите внимание на такие технологии, как AutoMapper. Вы можете сопоставить свои POCO Entity Framework с контрактом на обслуживание (XSD). С точки зрения клиента «вы могли бы» написать клиентский прокси, который вызывает вашу веб-службу, сопоставляет возвращенный контракт службы с красивой общей концептуальной объектной моделью.

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