Отношения между слоями
Если я хорошо понимаю ваш дизайн, бизнес-уровень не знает (= не использует) уровень данных, и фасад фактически связывает их, переводя DAO в DTO и наоборот.
Вам следует рассмотреть несколько иной подход: определить интерфейсы для всех объектов, связанных с данными (независимо от того, являются ли они DAO или DTO), и использовать контейнер Inversion-of-Control для объединения бизнес-уровня и уровня доступа к данным. Причина в том, что в вашем проекте вы можете быстро столкнуться с невозможностью получить дополнительные данные прямо на бизнес-уровне. Вы бы в конечном итоге заменили этот фасад фасадом и, следовательно, использовали слишком много реальной бизнес-логики.
В случае, когда вы устанавливаете четкую связь между бизнес-уровнем и базовым уровнем данных, разделяя их с хорошо разработанными интерфейсами и контейнером IoC, вы предотвращаете эту проблему, сохраняя при этом хороший и лаконичный внутренний дизайн.
Использование DTO
Я думаю, что все в порядке, что вы должны передавать DTO обратно в серверную часть вашего приложения. В вашем случае целью DTO является (1) предоставление информации для уровня представления и (2) предоставление способа передачи измененных или новых данных во внутреннюю часть для дальнейшей обработки. DTO для случаев (1) и (2) не обязательно должны быть одинаковыми. Следовательно, если это имеет смысл, вы можете передать бэкэнду только DTO, представляющий подмножество всей информации.
Однако после обработки серверная часть должна возвращать новый DTO, который, опять же, не должен быть тем же DTO, что и входной DTO. Таким образом, уровень представления может легко адаптироваться к изменениям, внесенным серверной частью в связанные части всего объекта.
Представьте себе простой API Get / Update, такой как этот:
CustomerDTO GetCustomer(int customerID);
CustomerDTO UpdateCustomerAddress(int customerID, AddressDTO address);
CustomerDTO UpdateCustomerPrimaryContact(int customerID, PersonDTO primaryContact);
Вы используете идентификатор для идентификации клиента и передаете в DTO, который представляет собой подмножество обновляемой записи клиента (независимо от базовой архитектуры данных). out DTO представляет клиента в целом, упрощая задачу уровня представления обновлений информации, отображаемой для пользователя. Преимущество заключается в том, что бэкэнду не нужно знать, какое подмножество данных клиента действительно необходимо для уровня представления, а уровень представления может передавать бэкэнду только те части, которые действительно были изменены.
Обновление - техническое примечание: Рассмотрите возможность использования такого инструмента, как AutoMapper (C #), для автоматизации переводов между DTO и DAO. Хотя этот вопрос является предметом используемой технологии, в целом такой подход экономит много ручной работы и способен устранить трудно обнаруживаемые ошибки. Наличие такой системы автоматизации перевода объектов помогает продвигать лучшие методы проектирования и позволяет создавать более специализированные и, следовательно, семантически более точные DTO.
Отказ от ответственности: Хотя это довольно общий вопрос, мои рекомендации могут показаться неправильными в отношении дополнительных деталей вашего заявления, которые не охвачены в вашем вопросе.