【发布时间】：2018-02-15 21:16:56
【问题描述】：
我已经在使用 DTO 通过网络传输数据。现在，我还将向 DAL 引入不同的类似 DTO 的类。这是为了避免跨层传递应用程序（业务）对象。
为避免命名混乱，我想使用 DTO 以外的其他术语，但找不到合适的术语。
从 DAL 返回的对象的 DTO 等效术语是什么？
【问题讨论】：
标签： data-access-layer dto
【发布时间】：2018-02-15 21:16:56
【问题描述】：
“名字里有什么？我们用任何其他名字称呼玫瑰都会闻起来很香。” - 威廉莎士比亚
另外，Martin Fowler says 对 POJO 的看法：
在演讲中，我们指出了将业务逻辑编码为常规 Java 对象而不是使用实体 Bean 的诸多好处。我们想知道为什么人们如此反对在他们的系统中使用常规对象，并得出结论，这是因为 简单的对象缺乏花哨的名称。所以我们给了他们一个，它很受欢迎。
顺便说一句，这并不重要。为避免因命名相似而引起的混淆，您可以从“DataModel”、“Entity”、“POCO”中进行选择。
以下是非常松散 考虑的不同常用术语：
关系模型[数据库层]：
- 数据库、表格和字段。
持久性模型[数据访问层]：
- （通常）属于 ORM 或与数据库紧密映射的模型。
- 这用于满足持久性需求。
领域模型/业务模型[业务逻辑/服务层]：
- 向 BLL/服务层公开的模型。
视图模型 [UI 层]：
- 向 View 公开的模型。
DTO：
- 仅保存状态并用于将数据从一层传输到另一层。
- 除了序列化之外没有任何行为/逻辑。
- 最好是可序列化的。
- 针对请求层设计；与数据库不相似。
- 没有自己的身份。
POCO：
- 它只是一个常规对象，不引用任何特定框架，也不遵循它们的接口或限制。
- 可与任何 ORM 一起使用的持久性无知对象。
- 保存数据库中的数据。
- 不一定可序列化。
- 针对数据库请求而设计。
- 可能具有验证逻辑或其他与 POCO 紧密绑定的逻辑（例如数据加密/列的唯一性）。
- 没有 Get、Save 等持久化方法。POCO 不会自行填充。
- 可能有自己的身份。
实体：
- 它必须有自己的身份并且可以唯一标识。
- 可以使用 DataContext 从数据库加载和保存到数据库的对象。
- 没有DataBaseContext就无法存在。
- 与特定 ORM 紧密绑定并实现其规则（默认构造函数、用于创建运行时代理的虚拟属性等）。
- 实体表示域模型和域逻辑。
型号：
- 用于表示任何保存数据的对象的通用术语。
- 以上所有对象，如果我们将其中任何一个放在 MV* 模式中，它就会变成 Model。
参考以下答案：
【讨论】：