Сопоставление несовместимых свойств из DTO с сущностью
Я рефакторинг веб-приложения, чтобы убедиться, что мои объекты всегда инициализируются в допустимом состоянии. Это означает, что я использую DTO для пользовательского ввода и сопоставляю эти DTO с моими объектами после проверки.
Однако некоторые свойства DTO нельзя напрямую сопоставить со свойствами сущностей. Если DTO содержит изображение в кодировке base64, а объекту требуется URL-адрес файла изображения, мне нужно сохранить base64 в файл в преобразователе, чтобы назначить URL-адрес этого файла объекту.
Это мог быть только я, но мне кажется, что такие вещи не относятся к DTO для сопоставления сущностей. Есть ли причины, по которым это может быть плохой идеей? Какие стратегии обычно используются для этого вида отображения?
Ответы 1
Мне кажется, что в вашем случае у вас нет простого процесса сопоставления ДТОs с Сущности, потому что у вас есть логика приложения в этом процессе. Хранение изображений где-то и получение URL-адреса/пути для этого изображения — это логика, специфичная для приложения, поэтому для этого вам, вероятно, понадобится Оказание услуг.
Приложения обычно имеют некоторый вид задачи или операции, который необходим для выполнения и определения поток приложения. Один из способов определить этот поток — использовать Команды и присоединить DTO к этим Команды.
Например, предположим, что у вас есть процесс регистрации, поэтому пользователь должен ввести некоторые данные, и вам нужно создать объект Счет.
В случае веб-приложения внешний интерфейс должен будет собирать информацию о пользователе, а также создавать и отправлять команду на серверную часть. В этом случае у вас будет Команда RegisterUserCommand. Эта команда будет содержать свойство Информация о пользователе DTO или свойства для информации о пользователе. Например:
RegisterUserCommand {
string UserName
string FirstName;
string LastName;
Image Avatar;
}
Следующее, что вам нужно, это Региструсеркоммандсервице или (Обработчик региструсеркоммандлер в зависимости от вашего вкуса и используемой терминологии), который будет обрабатывать/обрабатывать Команда. Вам также нужен StorageProvider, который будет предоставлять сервисные операции для хранения и извлечения изображений (может быть в файловой системе, Amazon S3, Dropbox и т. д.) и даст вам ссылку. Вот пример псевдокода
RegisterUserCommandService {
Process(RegisterUserCommand cmd) {
avatarLink = storageProvider.Store(cmd.Avatar);
account = new Account(cmd.UserName, ...., avatarLink);
accountRepository.Save(account);
}
Если вы расскажете мне больше о своем приложении, я могу привести пример для вашего конкретного случая.
Вот некоторые ресурсы, которые вы можете проверить:
- https://cqrs.wordpress.com/documents/task-based-ui/
- https://martinfowler.com/bliki/CommandOrientedInterface.html
- https://weblogs.asp.net/shijuvarghese/cqrs-commands-command-handlers-and-command-dispatcher
На самом деле я уже использую аналогичный подход к CQRS, но в этом конкретном случае DTO используется для представления объекта в форме, а также для его отправки и применения изменений к объекту. Данные для запроса и команды точно такие же; просто изображение нужно сохранить/преобразовать. Основная причина, по которой я задаю этот вопрос, заключается в том, что я часто вижу людей, ссылающихся на автосопоставление DTO, и мне интересно, как такие вещи, как изображения, могут автоматически сопоставляться. Вот почему я начал думать, что, возможно, такие вещи, как сохранение изображений, не относятся к картографам.
Однако, кроме этого, я не вижу реальной причины, по которой я не мог бы реализовать сохранение изображений внутри самого картографа. На самом деле маппер можно считать сервисом.
Согласен, что маппер это сервис и можно добавить сохранение изображений в процесс маппинга и нормально это делать :). Для меня недостатком является то, что это дает картографу еще одну ответственность: сохранение изображений, что, как я думаю, является логикой конкретного приложения. Если вы рассматриваете службу приложений картографа, то все в порядке. Если это операция службы, то проще понять поток приложения и более последовательно, если у вас есть другие службы. Если это небольшое приложение, похожее на CRUD, это не проблема :) Для больших приложений четко определенный поток упрощает реализацию и отладку.
Не могли бы вы опубликовать пример кода того, как вы это делаете сегодня? Это даст нам лучшее представление о том, как правильно консультировать вас.