在Entity Framework教程的介绍中，我正在查看使用Code First Migrations描述和演示创建和更改数据库表所花费的时间。在Code First Migrations中，已添加到DbContext子类的自定义类用于首次创建相应的数据库表。然后我们将看到如何将对这些类之一的更改（例如添加新属性）推送到数据库表。以下是我目前对此的看法：
所有这些定义类，从中创建数据库表，进行更改，将更改推送到数据库的能力似乎都针对那些不了解数据库和数据库语法的开发人员。我认为，如果开发人员不熟悉数据库设计和语法，无法在原生环境和目标数据库服务器的语法中执行此操作，那么他根本不应该这样做;特别是在抽象细节的环境中。换句话说，使用本机db工具和技术来创建数据库对象要容易得多，也更加清晰。
我的问题是，为什么专业开发人员或开发商会将这些技术用于任何形式的数据库对象创建或维护？
我应该补充一点，我不是要求这个问题来起诉那些正在使用它的人。我问这个问题，因为如果我遗失了一些东西，我想知道它是什么。
答案 0 :(得分：1)
首先，不要求使用Code First进行迁移。您可以使用数据库项目或Chris在此处提到的方法之一：http://cpratt.co/migrating-production-database-with-entity-framework-code-first/#at_pco=smlwn-1.0&at_si=54ad5c7b61c48943&at_ab=per-12&at_pos=0&at_tot=1
您的问题似乎更多地涉及Code First工作流程，其中存在许多争论点。将对象放在关系数据库之前并不是很多资深开发人员所熟悉的。
“似乎针对的是不了解数据库和数据库的开发人员 语法”
- EF的维基百科条目很好地说：“实体框架使开发人员能够以特定于域的对象和属性（如客户和客户地址）的形式处理数据，而无需关心底层数据库表和存储此数据的列。使用实体框架，开发人员在处理数据时可以在更高的抽象级别工作，并且可以使用比传统应用程序更少的代码创建和维护面向数据的应用程序。“
“为什么专业开发人员或开发商会使用 这些技术适用于任何形式的数据库对象创建或 维护？”
- 作为专业开发人员，您仍然需要了解OOD的租户（收容，组合等）并应用SOLID原则。 无论使用哪种工作流程，您仍然可以使用impedance mismatch.
顺便说一句，我在一家拥有非常严格的DBA的商店里工作。我们的团队仍然使用EF进行迁移，但我们使用漂亮的脚本生成技术为它们提供脚本来更新模式。它是每个商店或项目的正确工具吗？不。事实上，我们一直在研究Dapper作为一个更轻量级的层。