我使用 Entity Framework 作为我的 ORM，我正在尝试弄清楚如何解决我遇到的一些主要问题。让我描述一下我的团队的一些背景设置。
我们的数据库使用 SQL Server 2012，IDE 使用 Visual Studio 2012，源代码控制使用 GIT，ORM 使用 Entity Framework 。在我们的源代码管理中，我们在一个名为“master”的分支中进行开发。我们有一个“暂存”分支(用于测试)和一个“实时”分支(这是生产代码)。当我们进行修补程序时，我们会分支出最新的实时代码，将其推送到暂存区进行测试，然后在获得授权投入生产后将其推送到实时。完成之后，我们将 hotfix 分支合并回 master 分支。我们也遇到过这样的情况，即当前在 master 分支中的代码被精心挑选到一个修补程序分支中并上线。
在所有这些情况下，我们最大的痛点是 EDMX 文件。有数百个表和 proc 映射的东西是巨大的。我们现在处于一个时间点，我们一次只能让一个开发人员使用 EDMX 文件，因为 GIT 无法处理合并冲突。此外，我们曾尝试从 master 分支中挑选出合适的分支，但最终却遇到了 EDMX 合并噩梦。
我们根本无法继续这种方式，在我们控制 ORM 之前，我们当然不能雇用更多的程序员。我现在正考虑使用像 ORMlite 这样的新 ORM，这样我就可以摆脱 EDMX 文件。有没有人对这类问题有任何经验？可以做些什么来防止这些合并冲突和分支问题？我听说在 EF6 中将删除 EDMX 文件的谣言。这是真的吗？
最佳答案
我们在我们的环境中遇到了同样的问题。一个看起来很有前途的解决方案是转向 Entity Framework Code First(您在其中编写代码，生成数据库模式)而不是使用 EDMX 文件(其中代码从数据库模式生成)。 一个很大的优势是您可以完全控制 POCO，而不会得到一堆困惑的生成代码。合并它就像合并普通的 C# 类一样，不会引起同样的麻烦合并 EDMX 确实如此。
这里有一个工具可以先将现有的 EDMX 实现转换为代码:http://visualstudiogallery.msdn.microsoft.com/da740968-02f9-42a9-9ee4-1a9a06d896a2
下面是对 EF 不同方法的一个很好的总结，底部列出了每种方法的优点: https://www.simple-talk.com/dotnet/.net-framework/different-approaches-of-entity-framework/
更新:这是另一种简化 EDMX 合并难题的技术:删除 <Diagrams> XML 节点内容。此处有更多详细信息:http://blogs.teamb.com/craigstuntz/2010/02/03/38542
关于c# - 防止 EDMX 合并冲突和 Cherry Picking 问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19848243/