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
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论