组合DTO更新，最佳实践

Question

我有一个组合DTO，在其中属性是原始值或其他DTO（在许多地方出现）。

例如：

- PersonDto - Name - Surname - AddressDto - Street - Number - ContactDto - PhoneNo - EMail

在此示例中，AddressDto和ContactDto在许多其他DTO中使用（不仅是PersonDto），因此我倾向于向这些DTO添加一些业务逻辑。特别是我想向这些DTO添加更新逻辑（例如：定义IUpdateable接口）来处理DTO的信息持久化方式。

以这种方式，当我必须处理DTO时，我可以检查它是否是组合DTO，在这种情况下，我知道我可以依赖于父DTO中包含的IUpdateable子DTO来获得“正确的更新逻辑”。

但是我有一种感觉，这不是正确的方法，DTO（如名称所示）应该只携带信息而没有业务逻辑。我也不喜欢将逻辑附加到DTO中的想法，因为那么我就受限于该特定逻辑（如果我需要具有完全相同结构但不同更新逻辑的ContactDto，则我的唯一选择是派生一个新类型...，这似乎很丑陋）。

话虽如此，到目前为止，我已经沉迷于仅在DTO上使用接口，如果接口仅是描述DTO“范围”的“标记”，在这种意义上，它保证DTO将包含具有特定含义的某些属性。

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

- 我想“标记”DTO，以明确表明DTO可以用于某些功能（例如：在先前的示例中，DTO可在某种程度上存储） - 我希望明确和“封装”处理DTO功能的逻辑（存储DTO的方式）

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

- Skary

Answer 1

但我感觉这不是正确的做法，DTO（顾名思义）应该只携带信息而没有业务逻辑。

是的，你说得对。

特别是我想在这些DTO中添加更新逻辑。

如果您使用服务层架构，则应将逻辑放置在服务中。 最终，在您选择的任何架构中，都会有一些组件或层具有大部分业务逻辑。 阅读这篇关于在哪里放置逻辑的精彩答案。

- StepUp

---

我已经实现了一个业务层，在其中定义了逻辑（BL 依赖于 DAL，其中存储库定义了如何更新事物）；从这个意义上讲，我的实际架构符合您给我链接的列表中的第一点。所以如果我理解正确，在这种情况下，每当我在 BL 中使用包含 ContactDto（例如 PersonDto）的 DTO 进行更改数据的操作时，我都必须“记住”调用正确的 ContactRepository 更新逻辑。没有更进一步封装的方法，对吗？ - Skary

@Skary，没错。如果你正在使用服务层架构，那么你需要调用相应的存储库。在你的情况下，它是ContactRepository。 - StepUp

好的，谢谢。我本来希望可以更简洁些，但是重复一点也不是什么大问题。再次感谢您的帮助。 - Skary

@Skary 我很高兴它对你有帮助！ :) - StepUp