我使用实体框架作为我的ORM，我正在试图弄清楚如何解决我遇到的一些主要问题。让我描述一下我的团队的设置背景。
我们将SQL Server 2012用于我们的数据库，Visual Studio 2012用于我们的IDE，GIT用于我们的源代码控制，实体框架用于我们的ORM。在我们的源代码控制中，我们开发了一个名为“master”的分支。我们有一个“staging”分支（用于测试）和一个“live”分支（这是生产代码）。当我们执行修补程序时，我们将最新的实时代码分支，将其推送到暂存以进行测试，然后在授权进入生产后将其推送到实时。完成之后，我们将修补程序分支合并回主分支。我们还遇到过这样的情况：当前在我们主分支中的代码被挑选到一个修补程序分支并被推送到实时。
在所有这些情况下，我们最大的痛点是EDMX文件。事情是巨大的，有数百个表和proc映射。我们现在只能让一个开发人员一次使用EDMX文件，因为GIT无法处理合并冲突。此外，我们尝试从我们的主分支机构采摘到现场的时间，我们最终得到了EDMX合并的噩梦。
我们根本无法继续这种方式，在我们控制ORM之前，我们当然不能雇用更多的程序员。我现在正处于考虑使用像ORMlite这样的新ORM的地步，所以我可以摆脱EDMX文件。有没有人有这类问题的经验？可以采取哪些措施来防止这些合并冲突和分支问题？我听说有传言称在EF6中EDMX文件将被删除。这是真的吗？
答案 0 :(得分：0)
我们的环境遇到了同样的问题。一个看起来很有希望的解决方案是转向实体框架代码优先（在其中编写生成数据库模式的代码）而不是使用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