代码优先 w/existing 数据库 vs 数据库优先和版本控制并发开发
Code first w/existing database vs Database first and concurrent development with version control
我使用 EF6.x 已经有一段时间了，对它非常满意。然而，与大多数涉及团队的项目一样，由于某种错误或生产变更，您必须经常停止 "fix" 主分支中的某些内容（master branch/trunk 等）。如果您的代码涉及实体数据模型并且您所做的更改与数据库架构更改相关，那么如果您在 t运行k 中进行这些更改并尝试将追赶合并回已经启动的开发分支。这是我使用 DB 优先方法（包括 EF 设计器图表）的经验。
阅读了有关该主题的各种帖子后，我开始重新审视代码优先方法 w/existing 数据库。然而，上述情况是相当普遍的，至少对于我们团队而言。当它只是 C# 或 javascript 时，更改相对容易合并到开发分支中，而 EDMX 文件和其他与 EF 相关的工件则不然。
使用代码优先，如果要在主分支中处理数据库模式更改（生产修复等），那么我的选择似乎是：
(1) 自己更新与 EF 相关的 classes 并可能使用 EF 迁移，或者...
(2) 运行 再次通过 EF 模型逆向工程过程，覆盖那里的内容。如果保持模型名称不变，则首先必须删除现有文件，否则向导会报错。
对于数据库优先，由于会导致合并冲突，似乎我只能做这种事情。所以唯一的选择是只在单个分支中工作，如果你想避免合并问题，只能在主线分支中进行与代码相关的更改。
如果您的团队正在使用 Entity Framework 和某种版本控制（希望您是），那么您如何管理这种非常常见的场景中的更改？
[更新]
感谢埃里克，我想我有一个解决方案。
我也遇到过这个问题，但是在第一个逆向工程步骤之后并没有看到太多关于 "round trip" 能力的信息。所以我继续创建一个小型虚拟数据库以及一个带有 class 库的虚拟控制台应用程序。然后我引入了这个 Reverse poco 模板...更改了数据库中的一列，更新了 tt 文件，并且在我保存后（如 tt 文件中所述），我的模式更改反映在 POCO class是的。太棒了 - 这可能是我转储 edmx 文件的门票，我从来没有使用过它，并且可能会启用分支之间的代码合并。
我使用 EF Reverse Poco 模板，它只更新现有的 类，代码更新很容易合并。试一试。
我使用 EF6.x 已经有一段时间了，对它非常满意。然而，与大多数涉及团队的项目一样，由于某种错误或生产变更，您必须经常停止 "fix" 主分支中的某些内容（master branch/trunk 等）。如果您的代码涉及实体数据模型并且您所做的更改与数据库架构更改相关，那么如果您在 t运行k 中进行这些更改并尝试将追赶合并回已经启动的开发分支。这是我使用 DB 优先方法（包括 EF 设计器图表）的经验。
阅读了有关该主题的各种帖子后，我开始重新审视代码优先方法 w/existing 数据库。然而，上述情况是相当普遍的，至少对于我们团队而言。当它只是 C# 或 javascript 时，更改相对容易合并到开发分支中，而 EDMX 文件和其他与 EF 相关的工件则不然。
使用代码优先，如果要在主分支中处理数据库模式更改（生产修复等），那么我的选择似乎是：
(1) 自己更新与 EF 相关的 classes 并可能使用 EF 迁移，或者...
(2) 运行 再次通过 EF 模型逆向工程过程，覆盖那里的内容。如果保持模型名称不变，则首先必须删除现有文件，否则向导会报错。
对于数据库优先，由于会导致合并冲突，似乎我只能做这种事情。所以唯一的选择是只在单个分支中工作，如果你想避免合并问题，只能在主线分支中进行与代码相关的更改。
如果您的团队正在使用 Entity Framework 和某种版本控制（希望您是），那么您如何管理这种非常常见的场景中的更改？
[更新]
感谢埃里克，我想我有一个解决方案。
我也遇到过这个问题，但是在第一个逆向工程步骤之后并没有看到太多关于 "round trip" 能力的信息。所以我继续创建一个小型虚拟数据库以及一个带有 class 库的虚拟控制台应用程序。然后我引入了这个 Reverse poco 模板...更改了数据库中的一列，更新了 tt 文件，并且在我保存后（如 tt 文件中所述），我的模式更改反映在 POCO class是的。太棒了 - 这可能是我转储 edmx 文件的门票，我从来没有使用过它，并且可能会启用分支之间的代码合并。
我使用 EF Reverse Poco 模板，它只更新现有的 类，代码更新很容易合并。试一试。