当您可以直接在数据库中执行 SQL 时，运行 EF 迁移有什么意义？答案

【问题标题】：What's the point of running an EF migration when you can SQL directly in database?当您可以直接在数据库中执行 SQL 时，运行 EF 迁移有什么意义？
【发布时间】：2018-09-01 23:04:37
【问题描述】：

How to create View (SQL) from Entity Framework in ABP Framework

由于声誉原因，不允许发布 cmets。只是尝试获取有关将数据库连接到实体框架的更多信息，而无需切换到代码优先的开发风格。查看选定答案的响应（他告诉 OP 基本上做他将在数据库中做的同样的事情，但使用 EF，然后添加一个额外的步骤，其中 EF "...ignores..." 前面的说明...

我想直接在 SQL 中创建表和设计数据库，并让 csharp 库只读/写表值（有点像 dapper 在不替换数据库的情况下如何工作，只是工作旁边）。

这些教程没有讨论如何将您的数据库与您的项目集成。它要么brushes over the subject、ignores it completely，要么讨论如何替换它。

我不想做任何 EF migrations（我不想/不需要在每次决定运行、复制或转移项目时销毁/创建数据库）。任何和所有数据库回溯（备份/恢复）都应该通过 SQL 完成（在我的工作环境中）。

只是为了明确我想要学习的内容：专门从事数据库管理（构建数据库架构、管理和监控数据，并已建立现有数据库并建立数据）的人如何连接到项目以获取数据（再次，特别是引用 Dapper 的 Query 功能）。

我想集成和设计微服务，有些可能共享同一个数据库连接或依赖另一个。但我只是想在一个干净的强类型类实体中读取数据，如果必须的话，可能会在其他地方处理插入/更新。

我更喜欢使用 Dapper 而不是 EF，但 ABP 与 EF 的设计高度集成，避免它比仅仅使用它更令人头疼。

【问题讨论】：

搜索“Code First to an Existing Database”，这是从现有数据库开始的 EF 工作流，不使用迁移。例如：docs.microsoft.com/en-us/ef/ef6/modeling/code-first/workflows/…
@DavidBrowne-Microsoft 我研究了呃...现有数据库问题并查看了该特定文章。但是在 ABP 中，有更多的障碍需要跳过，这给我带来了很大的困惑，我不确定解决方案是否像文章显示的那样清晰和简单。示例new Entity in ABP 表示使用[Table('name')] 属性继承其他类和其他一些教程参考...我收到很多混合信号，我希望一切都遵循一种简单的方法。
我之前提到的问题的一部分，我很想利用多个数据库连接来创建一个更完整的包来使用更小的组件。但是 ABP 具有完整的设计结构，其中心是从单个节点继承所有内容。不确定从哪里分支，以及是否会导致他们无法沟通的问题。尤其是因为用户 Context.Session 与 Abp.DbContext 绑定，并且教程告诉我创建一个新的 DbContext 来同步我的数据库表...... idk 如何理解不同层的信息。

标签： entity-framework aspnetboilerplate asp.net-boilerplate

【解决方案1】：

您应该能够像使用 DB-first 配置的任何其他项目一样在 ABP 下映射 EF。

我用于 EF 的一致方法：（DB-First）

定义实体以匹配表/视图结构。
根据需要为关系定义扩展 EntityTypeConfiguration<TEntity> 与关联的 ToTable()、HasKey() 和任何 HasMany/HasRequired/HasOptional 的配置类。
在 DbContext.OnModelCreating:modelBuilder.Configurations.AddFromAssembly(GetType().Assembly); 加载所有实体配置。（假设 DbContext 与模型/配置在同一个程序集中替换 GetType().Assembly 以指向实体程序集。
关闭迁移。在 DbContext 构造函数中：Database.SetInitializer<MyDbContext>(null);

EF 提供的不仅仅是将表映射到类。通过映射实体之间的关系，EF 可以帮助生成优化查询以跨这些相关实体检索数据。这可以让您在不返回不必要的数据的情况下展平数据结构，取代对视图的需求，并且通常减少从数据库到应用程序服务器的数据量。

【讨论】：

明确一点，步骤 2-3 是不需要的，对吧？ What's the point of running an EF migration when you can SQL directly in database? 您不需要映射HasKey 和ToTable，因为“...EF 可以帮助生成优化查询以跨这些相关实体检索数据...”如果/当您这样做？尽管我喜欢消除一项任务并将其汇集到另一项任务的想法。我仍然想保持 DBA 的角色不变，这意味着我可以在不使用 C# 代码替换 SQL 的情况下执行相同的任务？
你要替换什么任务？配置类告诉 EF 架构及其关联方式。如果您的架构遵循带有注释提示的可预测约定，EF 可以自动获取类并解释架构，尽管许多现有架构并非如此。您还可以使用架构设计器生成 EDMX 供 EF 使用，但这可以遇到类似的问题。所以，正如我所提到的，上面是一种“一致的方法”，可以很好地处理现有的模式。最终选择是你的。你总能找到一份不同的工作。 :)
对不起，我只是想确认我对它的功能的理解是准确的。解雇您的 DBA 并让您的 C# 开发人员通过您的应用程序执行 SQL/DB 请求没有任何问题。那只是更少的人和部分参与其中。但我想知道，在不改变现状的情况下，是否可以做同样的事情并简单地使用 EF 作为映射工具（与 Dapper 的功能完全相同）？我不想要一些侵入性的东西导致我改变我做事的方式。我只是想让它与我已经在做的事情一起工作......
您可以创建视图并将实体映射到视图，但我只建议只读访问。我不确定还有什么问题。 EF 通常需要某种形式的配置来理解架构。它不需要被允许修改模式。（迁移）EF 确实需要了解 PK，尽管 FK 是可选的，因为您可以使用 Join 编写 linq 查询，但我不推荐这种方法，因为它是“冗长的”，并且是另一种类似 SQL 的语法变体，具有自己的细微差别.映射关系让对象模型能够理解架构。