BT

Working Around Entity Framework's Large Data Model Issues

| by Jonathan Allen Follow 578 Followers on Dec 02, 2008. Estimated reading time: 1 minute |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT