何时在MVC4应用程序中使用DTO（数据传输对象）？

我读过很多关于仅在需要时才使用模式的信息。我目前正在编写一个非常简单的应用程序，它实现了存储库和服务模式 - 我正在辩论是否将我的域对象传递给使用DTO的视图。这是一个单页面应用程序。何时在MVC4应用程序中使用DTO（数据传输对象）？

我开始在我的模型中创建DTO类，但仍不明白它们提供了哪些好处。感觉就像我无缘无故地复制了一切。

何时适合使用DTO？它在什么时候变得必要或有益？任何示例/样本都会很棒。

2013-03-01 RobVious

链接的问题不是这个问题的重复。这一个是关于在DTO或域对象（模型）之间进行选择的，而关联的问题是关于DTO的。 – Arashsoft 2016-01-28 14:20:57

我开始在我的模型中创建DTO类，但仍不明白它们提供了哪些好处。

那么在这种情况下很可能会出现这样的情况，即它们不提供益处。坚持最简单的方法总是最好的，所以你可能会试图不必要地增加复杂性。

我会说，当你只需要传递一些平面数据而不需要复杂的域对象时，DTO就很有用。在我看来，如果可能的话，最好是将您的视图直接绑定到您的业务对象。如果没有其他的，它提供了一个健全的检查，你的业务对象符合你的使用场景。事实上，这是the CSLA framework（其中包括）着重于业务对象的方法。

最常见的情况，我发现自己翻译域对象到DTO的是：

当我有一个外部服务的抽象依赖（这本身不符合我的内部域对象对齐）和我希望使服务接口本身非常简单。我没有在服务层做所有的翻译，而是使用DTO本身并在两者之间建立翻译层。
当我通过AJAX调用将序列化对象返回给JavaScript时，并且不希望我的域对象的所有额外开销都通过线路传递。保持JavaScript本身更简单，不通过外部网络连接传输不必要的数据等。
当我有一个视图使用各种域对象数据的组合，但不是其超集。在某些情况下，这可能表明这个视图表示一个用例，它有利于它自己的域对象（可能是其他对象的组合，或者所涉及的所有对象应该是较小的非聚合根对象的组合），所以要小心这种情况。但有时只是制作一个中间的DTO可以让代码更简单，更简洁。

我认为关键在于从一种形状的数据转换到另一种形状。如果在服务，控制器或视图中进行大量的翻译...那么也许这种翻译是一个足够大的组件，以适合自己的目标。这完全是关于分离问题，真的。一个好的经验法则是，如果一段代码“为了达到某种目的而重新塑造数据和”，那么这段代码就是做了两件事。将它分成两段代码可能会更好。 DTO是这两个人如何沟通的。

有一些工具（如AutoMapper）可以帮助大量的“脚手架”代码之间翻译志趣相投的对象之间进行翻译。

来源

2013-03-01 01:44:27 David

非常感谢大卫。在你使用DTO的情况下，你的Repository层是否可以处理？或者你会专门在服务层中使用一种方法来转换对象（将GETTING与TRANSFORMING分开）？ – RobVious 2013-03-01 01:48:57

@RobVious：我没有在我的仓库中使用DTO，没有。我倾向于认为存储库基本上是一个用于保存和检索域对象的工厂，最好是根对象（根据各种因素，它们可能会在内部延迟加载或急切加载其子对象）。一般来说，我的DTO尽可能接近我的代码的边界。（例如，仅用于视图中或仅用于向外部供应商的后端Web服务调用。） – David 2013-03-01 01:52:29

非常感谢David的详细信息。 – RobVious 2013-03-01 02:08:55

何时在MVC4应用程序中使用DTO（数据传输对象）？

回答

相关问题