类名：追加DTO或实体

Question

在类名后面添加DTO或Entity，有没有任何偏好？

是否有任何标准规定这个问题？

一个类用于ORM(EntityFramework)，另一个类用于序列化。

原因是为了避免所有字段的重复，因为EntityFramework是DTO类(大多数但不是全部属性)的包装器。

DTO类位于共享库中，与EF解耦。

例如，哪种方法最常见/标准？

// 1.
MyNamespace.Entities.MyClass
MyNamespace.Models  .MyClassDto


// 2.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models  .MyClass


// 3.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models  .MyClassDto

- Michal Ciechan

---

这在很大程度上取决于个人喜好。一个适当的经验法则是：它是数据传输对象吗？那就使用“Dto”后缀。它是数据库实体/实际数据吗？那就不要使用任何后缀。 - Ondrej Tucny

我可以在哪里提出这样的问题？Reddit吗？ - Michal Ciechan

Answer 1

在我的个人经验中，你的第三个例子是我使用过的唯一实现方式，我会为它辩护，因为你正在处理的对象的意图总是很清楚的，而对于其他两个，只有在同时查看两个对象时才变得清晰。 话虽如此，只要你的团队达成一致意见，任何一种都可以。

- user1618236

Answer 2

在我看来，通常不应该将实现细节放入类名中，原因类似于为什么不应该使用匈牙利命名法。 如果有一部分代码需要处理两种类型并区分它们，另一个选项是包括类似这样的别名使用语句：

using entities = MyNamespace.Entities;
using dto = MyNamespace.Models;

//in code
var myClassEntity = new entities.MyClass();
var myClassDto = new dto.MyClass();

//work with both

我的假设是需要处理这两种类型的代码仅限于一个独立的库中，而客户端代码通常只与其中一种类型交互。

- Colin

---

这就是我目前所拥有的 :-( 它很痛苦，而且很丑陋，特别是当你有一个通用的东西需要到处传递时 + 一堆工具都将其报告为一个关键问题，我的团队对此表示不满 :-( - Michal Ciechan

诀窍在于让消费者只能引用一种类型，而不是两种类型，因此它只需要在数据访问/转换代码中使用。如果“实体”类仅用于数据访问，则将它们封装在库中，以便只有该库需要处理两种类型。唯一必须处理两种类型的类应该是一些简单的转换器，然后只需从那里传递一个可解析的类型即可。否则，您可能会使用名称更改来隐藏可能存在的工程问题。 - Colin