将 DTO 对象传递给服务层不是不好的做法吗？
现在我的服务层方法如下所示：
public save(MyEntity entity);
从 DTO 到业务实体 (MyEntity) 的映射值在表示层上完成
但我想将方法签名更改为：
public save(MyEntityDTO dto, String author);
之后，从 DTO 到业务实体的映射将发生在服务层。
编辑：我想要它，因为从 DTO 映射到业务对象时我需要打开休眠会话，因此实体上的所有更改都将自动刷新。
问问题
8213 次
3 回答
15
将 DTO 对象传递给服务层不是不好的做法吗？
您不仅可以将 DTO 对象传递给服务层，还应该将 DTO 对象而不是业务实体传递给服务层。
您的服务应该接收 DTO，将它们映射到业务实体并将它们发送到存储库。它还应该从存储库中检索业务实体，将它们映射到 DTO 并将 DTO 作为响应返回。因此，您的业务实体永远不会脱离业务层，只有 DTO 会这样做。
在此处查看类似问题的完整答案。
于 2015-10-15T18:09:27.883 回答
0
没关系，所有标准的 3 层架构都这样做。数据访问获取数据、业务地图并对其进行操作，演示呈现它。这是不行的 - 但是，正如所说的没有犯罪 - 将数据访问模型传递给演示 - 在这一点上你应该传递业务模型。顺便提一句。“DTO”可以表示任何东西，业务层模型可以是 DTO，数据访问模型可以是 DTO。DTO 通常是 C# 中的 POCO。通常你有你的数据访问模型，代表你的数据库实体和你的域模型，它们在你的应用程序周围传递数据。域模型通常是 DTO（或称其为 POCO）。这意味着，在 Microsoft 演讲中，它们是完全可序列化的，因此您可以将它们传递给任何 microsoft .net 组件。您还可以将它们序列化为 xml、json 等...
于 2013-11-20T10:45:57.663 回答
0
这是值得商榷的。（正如对已接受答案的评论所证明的那样）一方面，DTO 属于处理数据传输的应用程序层，这显然是您的表示层。
另一方面，在服务层中正确处理的域对象（业务实体）可能具有其中的属性 - 例如 Id、LastUpdated 等未传递到 save 方法的属性。那你传入什么？好吧，你只传递你需要的属性。碰巧的是，对 save() 的请求 MyEntityDTO 将恰好封装所有且仅封装这些属性！...
所以你现在有以下不幸的选择：
从表示层传入业务对象
（也破坏了分层模型，并迫使您忽略 Id 和 LastUpdated 等不在“请求”中的属性）
将 DTO 分解为属性并将其传入：
service.save(Dto.Property_One, Dto.Property_Two)然后你必须在 save() 方法中重新组合。
创建一些新对象来封装 Property_One、Property_Two 等
接受 DTO 也用于在层之间传输
这些都不是理想的imo，这就是为什么我认为＃4还可以。可能最正确的是＃2 - 但同样......不理想。
有时将我的痛苦命名为：“MyEntityRequest”而不是“DTO”
于 2021-12-07T13:19:24.667 回答