Entity framework EDMX还是不再EDMX？

我有点困惑：随着EF的发展，我不知道我现在在哪里

*EDMX是否是过去的选择，是否应该继续使用？ *如果是这样，最好的选择是什么？ *我讨厌edmx，我可以先升级到代码吗

现在还不清楚这些EF版本对我来说是什么

谢谢

---

Jonathan

对于许多应用程序，如果您愿意，可以先开始使用代码。CodeFirst还不支持的一件大事是映射到存储过程。（您仍然可以调用存储过程，但不能将实体CRUD操作映射到它们。）

也就是说，使用EDMX首先创建数据库仍然是绝对受支持的，也是一个不错的选择，特别是您喜欢使用EF设计器

EF4.1及以上版本完全支持代码优先和数据库优先

---

就个人而言，我几乎总是选择代码优先，即使是在现有数据库中，因为我是一个以代码为中心的人，我更愿意将所有映射保存在代码中，这样我就可以轻松地重构、在源代码管理中管理、拆分为多个文件等等，处理代码工件比处理单一的XML文档容易得多，也更好。

这是您应该如何评估实体框架使用情况的：

1） EDMX是一个完全有效的选项，特别是如果您有一个现有数据库，并且希望根据数据库模式生成实体。我最喜欢的好处之一是低风险的快速数据层开发。另外，当您要处理复杂的现有存储过程时，将存储过程结果映射到类总是很好的

或

2） 如果您想创建基于面向对象数据模型的数据库，代码优先是一个完全有效的选项。首先使用代码可以很容易地进行大型重构，直到实现时您才会想到这些重构。源代码管理在代码中更为常见，而搁置/回滚是一个很好的特性

TL；灾难恢复版本：

---

它们都是完全可行的选择。两者都不过时；它们也不会很快出现

我们在热身时首先考虑了EF代码的性能。EF代码首先需要几分钟来启动，因为我们有数千个实体。因此，这个瓶颈迫使我们使用EDMX，并用于在实体模型更改后的第一次运行中从代码开始创建EDMX，在其他第一次运行时，预热时间大大缩短

但故事并没有就此结束。在开发区域中，我们看到在实体模型中做了很多更改，所以在每次更改之后，应该经常重新创建（更新）EDMX文件。因此，我们决定以编程方式创建EDMX，并优化实体模型的创建