c# - 复合 Dto 更新，最佳实践

Question

我有一个复合 Dto，其中属性是原始值或其他 Dto(出现在许多地方)。

例如:

• PersonDto
  • 姓名
  • 姓氏
  • 地址Dto
    • 街道
    • 人数
  • 联系方式
    • 电话号码
    • 电子邮件

在此示例中，AddressDto 和 ContactDto 用于许多其他 Dto(不仅是 PersonDto)，因此我很想向这些 Dto 添加一些业务逻辑。特别是我想向那些 Dto 添加更新逻辑(例如:定义一个 IUpdateable 接口(interface))以处理 Dto 如何持久化信息。

这样，当我必须处理 Dto 时，我可以检查它是否是复合 Dto，如果我知道我可以依赖父 Dto 中包含的 IUpdateable 子 Dto 来获得“正确的更新逻辑”。

但我觉得这不是正确的处理方式，Dtos(顾名思义)应该只携带信息而没有业务逻辑。我不喜欢开始将逻辑附加到 Dto 的想法，因为那样我就受限于那个特定的逻辑(如果我需要一个 ContactDto 具有那个确切的结构但不同的更新逻辑，我唯一的选择是派生一个新类型..和这看起来很丑)

也就是说，到目前为止，我沉迷于在 Dtos 上使用接口(interface)，前提是该接口(interface)仅仅是一个描述 Dto“范围”的“标签”；从这个意义上说，保证 Dto 将包含一些具有特定含义的属性。

但现在我不清楚如何实现两个目标:

• 我想“标记”Dto 以明确表明 Dto 可用于某些功能(例如:如前例所示，Dto 可以以某种方式存储)
• 我想说清楚并“封装”处理 Dto 功能的逻辑(存储 Dto 的方式)

可选地，我想以最简单的方式实现上述目标，而不需要太复杂的架构

Answer 1

But i have the feeling this is not the correct way to proceede, Dtos (as name imply) shuld carry only information and no business logic

是的，你完全正确。

In particular i would like to add update logic to those Dtos

如果使用服务层架构，逻辑应该放在服务中。 Ultimately, in any architecture you choose, there is going to be some component or layer that has most of the business logic.阅读这个关于您的逻辑应该放在哪里的漂亮答案。