我理解基于DataBaseFirst方法生成模型会在ORM上生成一组基本上映射到数据库表的权限。
我的理解是，如果您需要来自其他实体的属性或只需要下拉列表字段，您可以创建一个ViewModel并将该类用作您的模型。
我有一个AppDev课程，我刚刚完成，作者写了一些内容，如果我理解正确，他指的是更改ORM实体以适应您的ViewModel的样子，因此，不需要ViewModels。但是，如果您这样做，并从数据库重新生成ORM，那么您放置为“ViewModels”的新实体将会消失。如果您更改了ORM以更新数据库，则SQL Server中的数据库结构将“撤消”。
如果我的理解是正确的，请告诉我，我只需要在单独的文件夹中使用ViewModel来收集超类或单个类中的特定类和/或属性，并使用我需要的属性并将其用作我的模型....
以下是作者的摘录： EntityFramework最初是类到表的一对一映射，但无论数据如何存储在关系表中，您都可以创建更好地表示应用程序中实体的模型。
答案 0 :(得分：1)
我认为作者可能暗示的是复杂模型的概念。比方说，例如，在您的数据库中，您有一个Customer表和一个Address表。一对一映射将创建2个模型项，一个Customer类和一个Address类。使用复杂模型映射，您可以创建一个Customer类，其中包含Customer表和Address表中的列。因此，您可以简单地引用Customer.Address.Street1而不是Customer.Street1。这只是许多情况中的一种，您可以在代码中表示概念模型的方式与存储中的结果数据不同。查看优秀的博客系列Inheritance with EF CodeFirst，了解不同映射策略的示例，如表每层次结构（TPH），每种类型表（TPT），每个混凝土类表（TPC）。请注意，即使这些示例是CodeFirst，它们仍然适用于Entity Framework，即使初始模型是从数据库生成的。
通常，如果使用DatabaseFirst然后从不修改生成的实体，则数据库中的每个表的代码中始终都有一个类。但是，Enity Framework的强大之处在于它允许您通过允许这些混合映射来更有效地与您的实体一起工作，从而使您可以自由地思考您的代码，而不必担心类的额外负担必须遵守严格的SQL期望。
修改
生成Database-First或Model-First实体时，会故意将它们生成为部分类。您可以创建自己的部分，这些部分扩展了从Entity Framework生成的类，而无需修改现有的类文件。如果重新生成模型，则您的部分类仍将保持不变。当然，使用partials意味着您拥有Entity Framework默认行为以及扩展行为，但这通常不是一个大问题。
另一个选择是您可以修改实体框架用于生成模型的TT文件，确保您的模型始终以相同的状态重新生成。
最终，主要的想法是，仅仅因为实体框架的默认行为是将数据库映射到类1：1，还有其他选项，您永远不会被迫进入对您的项目无效的东西。 / p>