在我的项目中，我使用的是 EF Code First 方法。我有一个存储层、服务层和表示层（ASP.NET MVC）。我为每个视图使用一个专用的视图模型。
我感到困惑的是，我的服务应该将实体返回到控制器以将它们映射到视图模型，还是应该实现 DTO 并从服务中返回它们？
所以问题是当流程像“EF -> Repository -> Service -> UI”时，数据转换将是什么。“实体 -> DTO -> 视图模型”还是“实体 -> 视图模型”？
似乎如果我使用 DTO，它们会有点重复实体。
我正在尝试遵循最佳实践。
Use the DTO approach.
This will help you a lot to keep your application independent from database structure changes.
Mapping the EF entities up into the presentation layer will make any DB changes a pain to maintain. So many places you will need to keep an eye on.
As two examples of the different aproaches: Right now, I am working on a huge project that was originally binding directly to EF entities. This leads to all sorts of complications. There are parts that require extensive code changes for even small DB adjustments. On the other hand, at my home pet project, I was able to change the entire database system 3 times without troubles because I had good abstraction layers in between.
Especially now at the start, where your project architecture ist still clean, the work to implement the DTOs seems to be duplicated. But that may change over time when your several application layer start their own lives.
If you dread the seemingly duplicate work for implementing the DTOs, there are mapping libraries like AutoMapper that can take a lot of that pain away from you.
这很难说，因为这完全取决于您的应用程序及其复杂性。如果您有很多转换，我会说使用 DTO，如果不只是从实体转到 ViewModel。
一般来说，我会从尽可能少的转换开始。当事情变得复杂时，您仍然可以在两者之间添加另一层。请记住，添加抽象层比删除抽象层更容易。
MVC（以及几乎其他一般情况下）的最佳方法是执行 EF -> DTO -> ViewModel -> View。
您永远不应将 EF 用作绑定到视图的实体。你会打自己的脚，但也会违背 MVC 的目的——你的模型部分。
所以创建你的 EF，然后创建绑定到视图的模型。是的，看起来像是重复的工作，但实际上并非如此 - 它为您提供了更精细的控制，让您可以更精细地控制在模型中显示或包含的内容。
在一个理想的世界里，一切都将被分离而没有耦合。然而，在现实世界中，这并不总是务实的。
以您的情况为例，除非您使用的是 N 层架构（您似乎不是，更多的是分层架构）或者您的服务只对来自您的实体的非常有限的数据感兴趣，否则我会说 DTO 是过杀。与 EF 生成的代理实体相比，CodeFirst 实体非常轻量级，因此无需引入 DTO 来将相同的信息传送到另一层。
就我个人而言，我会让我的实体实现一个通用接口，然后我将使用它从我的服务层返回。这意味着您的服务有效地与您的 DAL 相关联（我想这不是那么好），但在您的情况下它可以完成这项工作。如果您以后改变主意，这使您可以灵活地在以后在服务层中换成实际的 DTO。