Entity Framework 的开发领导 Srikanth Mandadi 称这个包含两部分内容的文章为“解决 Entity Framework 中的大数据模型问题”,但很明显它的含义为“使用一些技巧”来解决这些问题。该文章首先谈到了无论对任何应用来说,期望的实体数量在 50 到 100 之间。超出这个范围会导致编辑器无法使用。
Entity Framework 有一些严重的性能问题。例如,每次使用一个新的连接字符串时,针对整个数据模型的基于 XML 的元数据都会被加载到内存中。如果你有一些共享通用数据模型的小型应用,那么向其中任何一个增加新的实体都会导致所有应用变慢。从本质上来说,这种限制使得我们无法将 Entity Framework 的数据模型放到共享库中。
视图的生成是 Entity Framework 设计上的另一个败笔之处。Srikanth Mandadi 解释到:
当查询或是 SaveChanges 第一次发生时,这个过程就开始了。视图生成步骤的性能不仅取决于模型的大小,还与模型之间的联系有关。如果两个实体通过一个继承链或是 Association 连接起来,我们就称其为连接的。与此类似,如果两张表通过一个外键连接起来,我们也称其为连接的。随着实体和 Schema 中表的连接数量的增长,视图生成的代价就越来越大了。
为了解决这些问题,Srikanth Mandadi 建议将大的数据模型划分为小的子集。有两种方式可以做到这一点,但感觉都不怎么样。
第一种仅仅是使用完全独立的子集。如果两个或多个子集都需要某张表,那么就为他们分别创建独立的实体。这种方式导致跨子集的直接调用无法实现,也容易导致实体的过度膨胀。
另一种方式是“使用”Schema 中的语法。IDE 不支持这么做,需要我们手工编辑 XML 以说明数据库需要使用另一个数据模型中的实体。除了手工编辑 XML 的痛苦外,它只能创建单向的连接。如果数据模型 A 使用了数据模型 B 中的实体,那么后者将无法引用前者。
你可以在 ADO.NET 团队的博客上阅读该文章第一部分和第二部分的所有内容。
查看英文原文: Working Around Entity Framework’s Large Data Model Issues
评论