Working Around Entity Framework's Large Data Model Issues

Posted by Jonathan Allen on Dec 02, 2008

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

Data Access ,

.NET

Tags

ADO.NET Entity Framework

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.

1. Back to top

   One thing I'd like to point out

   by Francois Ward

   Aside from the pain of hand-editing XML

   
   
   Only a very very small ubset of the entity framework's features are available from the GUI. For example, the extremely important ability to create an entity from a totally stand alone query, which does not map in any ways, shape or form to a physical table, not even partly. As far as I know, going in the XML is the only way to do it.
   
   So if you're using the Entity Framework for something serious, you're already hand editing the xml. I don't disagree with the rest of the point being made though.

   Reply

• Older >