Srikanth Mandadi, the Entity Framework Development Lead, calls the two-part article "Working With Large Models In Entity Framework", but it is clear they mean 'working around' it. The article opens with the expected number of entities for any given application, which is a measly 50 to 100 entities. Beyond that the editor becomes virtually unusable.
Entity Framework has some surprisingly glaring performance issues. For example, the XML-based metadata for the entire data model gets loaded into memory each time a new connection string is used. If you have a set of small applications that share a common data model, adding new entities to any one will cause them all to slow down. This limitation makes placing Entity Framework data models in shared libraries essentially untenable.
View generation is another area where Entity Framework's design shows significant failings. Srikanth Mandadi explains,
The process runs the first time either a query or SaveChanges happens. The performance of view generation step not only depends on the size of your model but also on how interconnected the model is. If two Entities are connected via an inheritance chain or an Association, they are said to be connected. Similarly if two tables are connected via a foreign key, they are connected. As the number of connected Entities and tables in your schemas increase, the view generation cost increases.
To work around these issues, Srikanth Mandadi suggests splitting large data models into smaller subsets. There are two ways to do this, both of which feel wrong.
The first is to simply use completely separate subsets. If a table is needed in two or more subsets, a separate entity is created for each one. This makes directly calling across subsets is impossible and leads to bloat.
Another option is the "Using" syntax in the schema. The IDE doesn't support this, it requires manually editing the XML to indicate one database should use entities from another data model. Aside from the pain of hand-editing XML, this can only create one-way links. If data model A uses entities from data model B, data model B cannot have references back to data model A.
You can read all of Part 1 and Part 2 on the ADO.NET Team Blog.