问题标签 [dto]

如果 JAX-RS 应用程序的方法将返回域对象，则表示（例如 JSON）将包含该对象的所有属性 - 对吗？但是如果这个对象包含不应该暴露给网络的“私人”数据呢？

从外到内的另一个方向是什么：如何防止私有字段被覆盖？

唯一的解决方案似乎是创建数据传输对象 (dto)。

除非无法指定要映射的字段，否则使用“自动映射器”不是解决方案。

那么，强制 JAX-RS 开发人员创建 DTO 吗？还是有其他解决方案？

我需要同步两个数据库。这些数据库存储相同的语义对象，但在两个数据库中物理上不同。

我计划使用 DTO 模式来统一对象表示：

DB ----> DTO ----> MAPPING (Getters / Setters) ----> DTO ----> DB

我认为这比在每一侧使用 SQL Query 进行物理同步更好，我使用 hibernate 添加抽象并同步对象。

你觉得，这是个好主意吗？

我有一个标准的域层实体：

它应用了某种验证属性：

如您所见，我已经完全弥补了这些属性。这里使用哪个验证框架（NHibernate Validator、DataAnnotations、ValidationApplicationBlock、Castle Validator 等）并不重要。

在我的客户端层中，我还有一个标准设置，我不使用域实体本身，而是将它们映射到我的视图层使用的 ViewModels（又名 DTO）：

然后假设我希望我的客户端/视图能够执行一些基本的属性级验证。

我看到我能做到这一点的唯一方法是在 ViewModel 对象中重复验证定义：

这显然不能令人满意，因为我现在在 ViewModel (DTO) 层中重复了业务逻辑（属性级验证）。

那么可以做些什么呢？

假设我使用像 AutoMapper 这样的自动化工具将我的域实体映射到我的 ViewModel DTO，那么以某种方式将映射属性的验证逻辑也传输到 ViewModel 不是很酷吗？

问题是：

1）这是个好主意吗？

2）如果可以，可以吗？如果没有，有什么替代方案（如果有的话）？

提前感谢您的任何意见！

我最近在我们的代码中遇到了这种模式（？），想知道它有什么用处，如果有的话。我们有一个使用 BlazeDS 的 Spring 应用程序和一个 Flex 前端。我们决定在 DTO 上使用接口，如下所示：

爪哇

动作脚本

DTO 上的接口能为您带来什么？这些是具有绝对零逻辑的轻量级对象。DTO 有意义，接口有意义，但不能一起使用。

根据具体情况，我经常需要针对同一资源使用多个 DTO。

以相册为例。根据我想要显示的内容，我需要将不同的数据放入我的 DTO（通过表单、列表、详细信息等创建）。

我将有一个albumFormDTO 来创建专辑，一个albumDTO 集合用于专辑列表，还有一个albumDetailDTO 用于详细专辑。

对于每一个，我都需要一个特定的汇编程序。这样做似乎真的很沉重。

看起来很愚蠢吗？

谢谢，Cya 本杰明。

首先是一些背景：

我有一个表单，我在其中回发了一些由 MVC 内置 ModelBinder 自动物化为对象的对象：

另外：我想强调的是，我们正在向 DTO (DataTransferObjects) 发布我们进一步向下映射到实体框架实体的线路图，因此我们不希望对 DTO 进行任何更改，除非可能添加属性。

问题

如果用户为“Hours”输入了一个无效值，比如“Fubar”，那么 ModelBinder 自然不会尝试设置“Hours”属性。但它默认为 0，因为它是int而不是string。

这当然给我带来了一些困难，因为现在我无法看到用户是否实际输入了 0，或者这是由无效输入引起的。

由于我使用的是自制的对象到实体（实体框架）映射器，因此我们无法将“小时”属性的足迹更改为int？. 我知道 MVC 有一些内置的验证，但我们宁愿不实现它，因为我们知道它受到了广泛的攻击，并且在 ASP.NET MVC 2.0 中有一些新的验证。

解决方案？

我需要能够向用户指出哪个字段不正确，这意味着我需要能够以某种方式捕获异常（或者可能是其他一些巧妙的解决方案？），在那里我可以做一些逻辑并发回一个新的向用户查看我澄清他们做错了什么的地方。

我目前的想法：编写自定义 ModelBinder。

你有什么建议？

将基本 setter 和 getter 以外的功能放入 DTO 是否合适？

背景

我们有自己的业务对象架构，一个更轻量级的（...并且松散地基于，但实际上并没有使用...）版本的“CSLA”业务对象框架，具有类似的用法、验证、包容性 DAL 等。所有生成代码（使用 CodeSmith 创建存储过程和业务对象）

业务对象在获取对象、具有过滤排序参数的列表以返回对象和通用列表的功能方面非常丰富。

这种架构可能不支持一种特定或流行的架构和纯粹主义，但它对我们来说效果很好，并且减少了很多手动编码。

我们发现很多的一件事，特别是在与其他系统（第 3 方、Flash 或 Silverlight 等）集成时，需要上下文化的“基本对象”或数据容器，这些容器可以轻松地序列化并跨 Web 服务等提供以用于特定目的。

环顾 SO 和网络，术语 DTO 出现了很多。我们在 Dto 命名空间中创建了这些基本对象，这些对象是代表基本或特定版本的业务对象的基本对象，但除了接受 DataRow 或业务对象以填充“Dto”对象的构造函数之外没有其他功能。

问题：

1)将其称为“DTO”对象是否正确？

2）与其让构造函数提供数据和设置对象属性，不如让这个填充代码在不同的类中，某种“帮助类”

关于我正在尝试做的术语和命名约定的任何评论？

谢谢

我有一个丰富的域模型，其中大多数类都有一些行为和一些属性，这些属性要么是计算出来的，要么是暴露成员对象的属性（也就是说，这些属性的值永远不会被持久化）。

我的客户只通过 WCF 与服务器对话。

因此，对于每个域实体，我都有一个相应的 DTO——一个仅包含数据的简单表示——以及一个映射器类，它实现DtoMapper<DTO,Entity>并可以通过静态网关将实体转换为其 DTO 等效项，反之亦然：

这个应用程序的服务器端主要是关于持久性，我的 DTO 从 WCF 服务进来，被反序列化，然后任意 ORM 将它们持久化到数据库，或者查询请求来自 WCF，ORM 执行该查询DB 并返回要序列化并由 WCF 发回的对象。

鉴于这种情况，将我的持久性存储映射到域实体是否有意义，还是应该直接映射到 DTO？

如果我使用域实体，流程将是

1. 客户端请求对象
2. WCF 向服务器发送请求
3. ORM 查询数据库并返回域实体
4. 映射器将域实体转换为 DTO
5. WCF序列化DTO并返回给客户端
6. 客户端反序列化 DTO
7. DTO通过mapper转化为领域实体
8. 创建的视图模型等

回程类似

如果我直接映射到 DTO，我可以消除每个对象、每个请求的一个映射。我这样做会失去什么？

唯一想到的是在插入/更新之前验证的另一个机会，因为我不能保证 DTO 在通过网络发送之前是否经过验证甚至作为域实体存在，我想有机会在选择时验证（如果另一个进程可能在数据库中放置了无效值）。还有其他原因吗？这些理由是否足以保证额外的映射步骤？

编辑：

我确实在上面说过“任意 ORM”，并且我确实希望事情尽可能与 ORM 和持久性无关，但是如果您有任何特殊的内容要添加到特定于 NHibernate 的内容，请务必这样做。

DTO 是否可以接受基于 DTO 数据返回派生值的实例方法？或者 DTO 应该是没有其他方法（除了 getter/setter）的纯数据容器吗？

我内心的纯粹主义者说，业务逻辑要潜入这种方法是非常容易的。但是，如果（例如）一个 DTO 在应用程序层之间共享，那么在 DTO 上使用此类方法可能存在争议。

您对此有何看法？有没有可以接受的情况，或者应该避免这种事情？为什么/为什么不？