实体框架团队已经建立了一个用户之声论坛，以便用户提交功能请求并对它们进行投票。我们聚焦当前得票率最高的 7 个功能请求，同时给出了你现在可用的潜在替代方法。
这些是至今为止请求频率最高的一些功能——
改进的 SQL 语句生成（状态 = 已启动）
该请求是——
我亲眼目睹，具有 4 或 5 个子查询的简单的 select 语句却产生了将近 5000 行的 SQL 语句，然而等效的手写 SQL 语句仅有 15 行。
对此微软已经取得了一些进展。他们的回复是——
对实体框架核心库的更新将包含在.NET 4.5 中，其中将会包括一些对于 SQL 语句生成的改进。然而并非评论中所提到的所有情形都将予以处理。
替代方法： 没有真正的替代方法，除非停止使用实体框架。
批量创建更新删除（CUD）支持 （状态 = 评估中）
对于业务线（LOB，即 Line of Business）应用程序而言，批量创建 / 更新 / 删除是一关键功能，而在大多数对象关系映射（ORM）工具中大概都没有此功能。像 DBase 和 PowerBuilder 等一些早期编程语言在几十年前已有此种能力。一些人甚至提出，对象关系映射（ORM）工具不适用于大容量事务，而更适合于在线交易处理（OLTP）及非批处理操作。
替代方法——
- 对实体框架的这个扩展提供了批量更新和删除的能力（但不能批量插入）。
- 不要使用实体框架进行大容量事务处理——请自行编写 SQL 语句。事实上，这可能是一处避免使用对象关系映射工具的理想位置。
实体框架支持二级缓存（Second Level Cache）（状态 = 评估中）
虽然这是 NHibernate 所支持的功能，但是对于实体框架却不是现成的。
替代方法——Julie Lerman 在她的文章“用实体框架和AppFabric 实现二级缓存”中演示了如何使用Windows Server AppFabric 实现二级缓存。
实体设计器：为拥有200 个以上实体的使用场景进行加速和优化
替代方法：一旦模型中的实体数目达到50 至100 时就把该模型拆解开来。这篇以往的博文仍可作为为什么支持此功能不仅是个技术难题而且对于用户体验也是挑战的相关解释。不知道是否微软将会考虑此功能，即使此功能已投票胜出。
多数据库支持（状态= 评估中）
由于模型目前始终被映射到单一数据库，因此该功能还不可用。
替代方法—— 需要使用同义词、并合并两个模型，从而骗过实体框架以便支持横跨多个数据库。
设计器支持使用GUID 作为实体键值（Entity Key） ——与其说这是个功能，不如说是个错误，当使用设计器为某个GUID 列添加StoreGeneratedPattern 属性时并不会更新数据模型的存储部分。当创建新记录时，这会导致GUID 列获得“000…” 的错误值。
替代方法—— 正如此文所解释的那样，请在.edmx 文件中手工添加StoreGeneratedPattern 属性。
按Rails 迁移的方式进行数据库架构（schema）迁移 （随着 Code-First 迁移完成即将与实体框架 4.3 一起到来）
此功能目前与实体框架 4.3 版本在一起处于测试阶段。有关此功能的更多细节参阅 MSDN 博客。
替代方法—— 使用数据库项目来创建升级脚本。一旦 Code-First 新版发布，则重建新的数据库架构（schema），并将其导入一个新的数据库项目中，然后将其部署到旧的数据库上。
还有许多由不同用户提出的其他有趣的功能想法，你一定要投票或者提交自己的想法，以便让实体框架团队知道对你而言什么功能是最重要的！
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论