7

我使用实体框架作为我的 ORM，并试图弄清楚如何解决我遇到的一些主要问题。让我描述一下我的团队的一些背景设置。

我们的数据库使用 SQL Server 2012，IDE 使用 Visual Studio 2012，源代码控制使用 GIT，ORM 使用 Entity Framework。在我们的源代码控制中，我们在一个名为“master”的分支中进行开发。我们有一个“暂存”分支（用于测试）和一个“实时”分支（这是生产代码）。当我们进行修补程序时，我们会分离出最新的实时代码，将其推送到登台进行测试，然后在授权投入生产后将其推送到实时。完成后，我们将 hotfix 分支合并回 master 分支。我们也遇到过这样的情况，即当前在我们的主分支中的代码被樱桃挑选到一个修补程序分支中并实时推送。

在所有这些情况下，我们最大的痛点是 EDMX 文件。这个东西很大，有数百个表和 proc 映射。我们现在只能让一个开发人员使用 EDMX 文件，因为 GIT 无法处理合并冲突。此外，当我们尝试从我们的主分支中挑选樱桃时，我们最终会遇到 EDMX 合并的噩梦。

我们根本无法继续这种方式，在我们控制 ORM 之前，我们当然不能雇用更多的程序员。我现在正在考虑使用像 ORMlite 这样的新 ORM，这样我就可以摆脱 EDMX 文件。有没有人对这类问题有任何经验？可以做些什么来防止这些合并冲突和分支问题？我听说在 EF6 中 EDMX 文件将被删除。这是真的？

4

1 回答 1

2

我们的环境中也遇到过同样的问题。一个看起来很有前途的解决方案是迁移到实体框架代码优先（您在其中编写代码，生成数据库模式）而不是使用 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

于 2013-11-07T22:59:21.513 回答