具有现有数据库的代码优先与数据库优先和具有版本控制的并发开发

Question

我使用 EF6.x 已经有一段时间了，并且对它非常满意。但是，与大多数涉及团队的项目一样，由于某种错误或某种生产变更，您必须经常停下来“修复”主分支（主分支/主干等）中的某些内容。如果您的代码涉及实体数据模型并且您所做的更改与数据库架构更改相关，那么如果您在主干中进行这些更改并尝试将追赶合并回已经存在的开发分支中，事情可能会变得一团糟开始了。这是我使用 DB-first 方法的经验，其中包括 EF 设计器图。

在阅读了有关该主题的各种帖子后，我开始重新审视现有数据库的代码优先方法。但是，上述情况相当普遍，至少对我们的团队来说是这样。当它只是 C# 或 javascript 时，更改相对容易合并到 dev 分支中，而不是 EDMX 文件和其他与 EF 相关的工件。

使用代码优先，如果要在主分支（生产修复等）中处理 DB 模式更改，那么我的选择似乎是：
(1) 自己更新与 EF 相关的类，并可能使用 EF 迁移，或者...
(2) 再次运行 EF 模型逆向工程过程，覆盖那里的内容。如果您保持模型名称相同，您首先必须删除现有文件，否则向导会抱怨。

使用数据库优先，由于会导致合并冲突，我似乎受限于做这种类型的事情。因此，唯一的选择是仅在单个分支中工作，并且如果您想避免合并问题，则只能在主线分支中进行与代码相关的更改。

如果您的团队正在使用实体框架和某种形式的版本控制（希望您也是），那么在这种非常常见的场景中，您如何管理更改？

[ 更新 ]
感谢 Erik，我想我有一个解决方案。 我也遇到过这个问题，但是在逆向工程师的第一步之后，我并没有看到太多关于“往返”的能力。所以我只是继续创建一个小的虚拟数据库以及一个带有类库的虚拟控制台应用程序。然后我拉入这个反向 poco 模板......更改了数据库中的一列，更新了 tt 文件，并且在我保存后（如 tt 文件中所述），我的架构更改反映在 POCO 类中。太棒了 - 这可能是我转储我从不使用的 edmx 文件的门票，并且可能会启用分支之间的代码合并。

Answer 1

我使用 EF Reverse Poco 模板，它只是更新现有的类，并且代码更新很容易合并。试试看吧。