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中的实体，那么后者将无法引用前者。