最想要的实体框架功能

作者 Roopesh Shenoy 译者 高翌翔 发布于 2012年2月10日

领域

语言 & 开发

主题

.NET框架 ,

.NET ,

数据访问 ,

编程 ,

数据库

分享到

实体框架团队已经建立了一个用户之声论坛，以便用户提交功能请求并对它们进行投票。我们聚焦当前得票率最高的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），并将其导入一个新的数据库项目中，然后将其部署到旧的数据库上。

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

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

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