问题标签 [data-transfer-objects]

我尊敬的一位导师建议，一个简单的 bean 是浪费时间 - 值对象“必须”包含一些有用的业务逻辑。

另一个人说这样的代码很难维护，所有的业务逻辑都必须外部化。

我意识到这个问题是主观的。无论如何都要问——想从更多的角度知道答案。

在通过 Hibernate 支持的事务服务方法传递数据时，是否有任何真正实用的方法可以避免使用 DTO？换句话说，DTO 是避免延迟初始化问题的唯一非 hacky 解决方案吗？

我认为 DTO 的两种流行替代方案以及我不太喜欢它们的原因是：

1. 在视图模式中打开会话。这是我不喜欢的，因为我想让服务方法真正具有事务性（即，当方法退出时，Hibernate 会话被提交并关闭）。这主要是因为如果我以后需要将服务发布为 Web 服务，我不想担心事务。

2. 通过服务方法而不是 DTO 传递域/业务对象，并急切地获取所需的属性/属性。这要好一些。然而，在具有复杂实体关系的非平凡领域对象层次结构中，急切的获取必须在某处停止。当它发生时，我看不出这不会很快变成一个完整的hackaton，用整个地方的引用ID替换实体。

从可维护性的角度来看，我是否遗漏了什么或者 DTO 实际上是唯一可靠的方法？

似乎没有太多细节的领域驱动设计的一部分是，您应该如何以及为什么应该将您的领域模型与您的界面隔离开来。我试图说服我的同事这是一个很好的做法，但我似乎没有取得太大进展......

他们在表示层和界面层中随心所欲地使用领域实体。当我向他们争辩说他们应该使用显示模型或 DTO 将域层与界面层隔离时，他们反驳说他们没有看到这样做的商业价值，因为现在你有一个 UI 对象要维护以及原始域对象。

所以我正在寻找一些具体的理由来支持这一点。具体来说：

1. 为什么我们不应该在表示层中使用域对象？
   （如果答案很明显，“脱钩”，那么请解释为什么这在这种情况下很重要）
2. 我们应该使用额外的对象或构造来将我们的领域对象与接口隔离吗？

在我的 Windows 窗体应用程序中，我有两个表示主从关系的 DataGridView。每个的数据源是一个数据传输对象，表示为一个 IList(of T)——所以 DataRelation 不存在了。驱动主从网格的最佳方式是什么？.NET 中是否有内置方法可以执行此操作，或者当所选主行更改时我是否必须编写自己的重新绑定？

什么是数据传输对象？

在 MVC 中是模型类 DTO，如果不是，有什么区别，我们需要两者吗？

谁能告诉我以下段落中API的含义，实际上是关于Transfer Object：

如果可能要求业务服务以粗粒度的大消息发送或接收其全部或大部分数据，则该服务通常会在其API中提供该功能。

提前致谢。

我最近无意中听到有人说数据传输对象(DTO) 是一种反模式。

为什么？有哪些替代方案？

我一遍又一遍地看到这种模式并想得到意见：

选项 1：关于连线对象和业务对象的组合：

在线对象 - 被序列化并在机器（客户端/服务器等）之间来回发送的数据。这是一个 POCO 对象。

例如：

Business Objects - 另一个类，通常具有部分或全部属性作为在线对象，但也有一些计算字段。这通常在“在线”对象之上使用合成。

选项 2：在有线对象和业务对象上通过转换：

这在连线对象上与示例 1 相同，但业务对象不使用组合，而是使用翻译：

选项 3：根本没有业务对象，并在单独的计算器类中完成所有计算。注意：消费者获得在线对象和计算器

我想就这里是否有最佳实践或模式征求人们的意见，或者这只是用户偏好的问题

在这种情况下，您有“传输对象”（只有 getter/setter 的 POJO），它们由客户端库传递到您的 API，那么命名传输对象的最佳方法是什么？

在此示例中，您的主类和传输对象都具有名称Car。它们位于不同的包中，但我认为名称相同会​​令人困惑。是否有关于如何命名传输对象的最佳实践？

在我工作的地方，我们已经在这个主题上反复讨论了很多次，并且正在寻找健全性检查。这里的问题是：业务对象应该是数据容器（更像是 DTO）还是应该包含可以在该对象上执行某些功能的逻辑。

示例 - 以客户对象为例，它可能包含一些常见属性（名称、ID 等），该客户对象是否还应包含函数（保存、计算等）？

一种推理方式是将对象与功能分开（单一责任主体）并将功能放在业务逻辑层或对象中。

另一种推理方式是，不，如果我有一个客户对象，我只想调用 Customer.Save 并完成它。如果我正在消费对象，为什么我需要知道如何拯救客户？

我们最近的两个项目将对象与功能分开，但在一个新项目上再次引发了争论。哪个更有意义？

编辑

这些结果与我们的辩论非常相似。一票或另一票完全改变了方向。还有人想加他们的 2 美分吗？

编辑

尽管答案样本很小，但似乎大多数人认为业务对象中的功能是可以接受的，只要它很简单，但持久性最好放在单独的类/层中。我们会试一试。谢谢大家的意见...