我正在重构一个网络应用程序，以确保我的实体始终以有效状态初始化。这意味着我使用 DTO 进行用户输入，并在验证后将这些 DTO 映射到我的实体。
但是，DTO 的某些属性不能直接映射到实体的属性。如果 DTO 包含 base64 编码图像并且实体需要图像文件的 URL，我需要将 base64 保存到映射器中的文件中，以便将该文件的 URL 分配给实体。
可能只是我，但感觉这种东西不属于实体映射器的 DTO。有什么理由说明这可能是个坏主意吗？这种映射常用什么策略？
【问题讨论】：
标签： mapping entity domain-driven-design dto
在我看来，在您的情况下，您没有从 DTOs 到 Entities 的简单映射过程，因为您在该过程中有应用程序逻辑。将图像存储在某处并获取该图像的 URL/路径是特定于应用程序的逻辑，因此您可能需要为其提供 Service。
应用程序通常有一些需要执行的任务或操作，并定义应用程序的流程。定义此流程的一种方法是使用 Commands 并将 DTO 附加到这些 Commands。
例如，假设您有一个注册过程，因此用户必须输入一些数据并且您需要创建一个帐户实体。
对于网络应用程序，前端必须收集用户信息并创建并向后端发送命令。在这种情况下，您将拥有 RegisterUserCommand。此命令将包含 UserInfo DTO 属性，或者将包含用户信息的属性。例如：
RegisterUserCommand {
string UserName
string FirstName;
string LastName;
Image Avatar;
}
接下来您需要的是一个 RegisterUserCommandService 或（RegisterUserCommandHandler 取决于您使用的品味和术语）来处理/处理 Command .您还需要一个 StorageProvider 来提供存储和检索图像的服务操作（可以在文件系统、Amazon S3、Dropbox 等上）并为您提供链接。这是一个示例伪代码
RegisterUserCommandService {
Process(RegisterUserCommand cmd) {
avatarLink = storageProvider.Store(cmd.Avatar);
account = new Account(cmd.UserName, ...., avatarLink);
accountRepository.Save(account);
}
如果您告诉我更多关于您的应用程序的信息，我可以为您的具体情况提供一个示例。
您可以查看以下资源：
【讨论】：