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