最想要的Entity Framework功能_最新动态_新闻资讯_程序员俱乐部

　　Entity Framework 团队已经建立了一个用户之声论坛，以便用户提交功能请求并对它们进行投票。我们聚焦当前得票率最高的 7 个功能请求，同时给出了你现在可用的潜在替代方法。

　　这些是至今为止请求频率最高的一些功能——

　　1、改进的 SQL 语句生成（状态=已启动）

　　该请求是——

我亲眼目睹，具有 4 或 5 个子查询的简单的 select 语句却产生了将近 5000 行的 SQL 语句，然而等效的手写 SQL 语句仅有 15 行。

　　对此微软已经取得了一些进展。他们的回复是——

对 Entity Framework 核心库的更新将包含在 .NET 4.5 中，其中将会包括一些对于 SQL 语句生成的改进。然而并非评论中所提到的所有情形都将予以处理。

　　替代方法： 没有真正的替代方法，除非停止使用 Entity Framework。

　　2、批量创建更新删除（CUD）支持 （状态=评估中）

　　对于业务线（LOB，即 Line of Business）应用程序而言，批量创建/更新/删除是一关键功能，而在大多数对象关系映射（ORM）工具中大概都没有此功能。像 DBase 和 PowerBuilder 等一些早期编程语言在几十年前已有此种能力。一些人甚至提出，对象关系映射（ORM）工具不适用于大容量事务，而更适合于在线交易处理（OLTP）及非批处理操作。

　　替代方法——

• 对 Entity Framework 的这个扩展提供了批量更新和删除的能力（但不能批量插入）。
• 不要使用 Entity Framework 进行大容量事务处理——请自行编写 SQL 语句。事实上，这可能是一处避免使用对象关系映射工具的理想位置。

　　3、Entity Framework 支持二级缓存（Second Level Cache）（状态=评估中）

　　虽然这是 NHibernate 所支持的功能，但是对于 Entity Framework 却不是现成的。

　　替代方法——Julie Lerman 在她的文章“用 Entity Framework 和 AppFabric 实现二级缓存”中演示了如何使用 Windows Server AppFabric 实现二级缓存。

　　4、实体设计器：为拥有 200 个以上实体的使用场景进行加速和优化

　　替代方法：一旦模型中的实体数目达到 50 至 100 时就把该模型拆解开来。这篇以往的博文仍可作为为什么支持此功能不仅是个技术难题而且对于用户体验也是挑战的相关解释。不知道是否微软将会考虑此功能，即使此功能已投票胜出。

　　5、多数据库支持（状态=评估中）

　　由于模型目前始终被映射到单一数据库，因此该功能还不可用。

　　替代方法—— 需要使用同义词、并合并两个模型，从而骗过 Entity Framework 以便支持横跨多个数据库。

　　6、设计器支持使用 GUID 作为实体键值（Entity Key） ——与其说这是个功能，不如说是个错误，当使用设计器为某个 GUID 列添加 StoreGeneratedPattern 属性时并不会更新数据模型的存储部分。当创建新记录时，这会导致 GUID 列获得“000..” 的错误值。

　　替代方法—— 正如此文所解释的那样，请在 .edmx 文件中手工添加 StoreGeneratedPattern 属性。

　　7、按 Rails 迁移的方式进行数据库架构（schema）迁移 （随着 Code-First 迁移完成即将与 Entity Framework 4.3 一起到来）

　　此功能目前与 Entity Framework 4.3 版本在一起处于测试阶段。有关此功能的更多细节参阅 MSDN 博客。

　　替代方法—— 使用数据库项目来创建升级脚本。一旦 Code-First 新版发布，则重建新的数据库架构（schema），并将其导入一个新的数据库项目中，然后将其部署到旧的数据库上。

　　还有许多由不同用户提出的其他有趣的功能想法，你一定要投票或者提交自己的想法，以便让 Entity Framework 团队知道对你而言什么功能是最重要的！

　　查看英文原文：Most-Wanted Features in Entity Framework

　　译者：高翌翔，基于 .NET 平台进行 Web 应用程序设计、开发，关注敏捷开发和架构设计，及各种提高代码可维护性的最佳实践。