我应该使用EF在存储库模式中实现DTO吗？

Question

在我的项目中，我正在使用EF Code First方法。我有一个存储库层，服务层和表示层（ASP.NET MVC）。我正在为每个视图使用专用的视图模型。

我感到困惑的是，我的服务是否应该将实体返回给控制器以将它们映射到视图模型，还是应该实现DTO并从服务中返回它们？

所以问题是当流程类似于“EF - ＆gt;存储库 - ＆gt;服务 - ＆gt; UI”时，数据转换将是什么。 “实体 - ＆gt; DTO - ＆gt; Viewmodel”或“实体 - ＆gt; Viewmodel”？

似乎我使用DTO，它们会有点重复实体。

我正在尝试遵循最佳做法。

谢谢。

Answer 1

使用DTO方法。

这将帮助您保持应用程序独立于数据库结构更改。

将EF实体映射到表示层将使任何DB更改都难以维护。你需要留意这么多地方。

作为不同方法的两个例子：现在，我正在开发一个最初直接绑定到EF实体的巨大项目。这导致了各种各样的并发症。有些部件需要进行大量的代码更改才能进行小的DB调整。另一方面，在我的家庭宠物项目中，我能够无故障地更改整个数据库系统3次，因为我之间有很好的抽象层。

特别是现在开始时，您的项目架构仍然很干净，实施DTO的工作似乎是重复的。但是，当您的多个应用层开始自己的生活时，这可能会随着时间而改变。

如果你害怕实现DTO的看似重复的工作，那么像AutoMapper这样的映射库会让你感受到很多痛苦。

Answer 2

这很难说，因为这完全取决于您的应用程序及其复杂性。 如果你有很多转换，我会说使用DTO，如果不是从实体转到ViewModel。

一般来说，我会从尽可能少的转换开始。当事情变得复杂时，你仍然可以在它们之间添加另一层。请记住，添加一个抽象层然后删除一个更容易。

Answer 3

MVC（以及其他几乎所有人）的最佳方式是做EF - ＆gt; DTO - ＆gt; ViewModel - ＆gt;图。

你永远不应该使用EF作为绑定到View的实体。你会用脚射击自己，但也会失去MVC的目的 - 你的模范部分。

所以创建你的EF，然后创建你的模型绑定到视图。是的，看起来像重复的工作，但实际上，它不是 - 它为您提供更精细的颗粒控制，以便在视图的模型中显示或包含的内容。

Answer 4

在理想世界中，一切都将被分开，没有耦合。但是，在真正的世界中，这并不总是务实的。

采用您的方案，除非您使用的是N层架构（您似乎不是更多层次架构），或者您的服务只对您实体的非常有限的数据感兴趣，我会说DTO过度杀戮。与EF生成的代理实体相比，CodeFirst实体非常轻量级，因此不需要引入DTO来将相同的信息传递到另一层。

就个人而言，我会让我的实体实现一个通用接口，然后我会用它从服务层返回。这意味着你的服务与你的DAL有效联系（我想这不是那个很棒）但在你的情况下它会完成这项任务。如果您稍后改变主意，这使您可以灵活地在服务层中稍后换出实际的DTO。