Entity Framework V4: Code Only Performance Considerations

Question

I'm going to start work on a new project, and I wonder if this is "Code Only" right. We are also considering a different model-based approach using a constructor, but would prefer to develop my domain models outside of the EF designer.

There are likely to be more than 100 objects in our domain. I read that a huge number of objects can slow down EF somewhat (i.e. Creating a context and the first call to SaveChanges).

Since there is no EDMX file for storing metadata, will this approach be slower? I searched the Internet but could not find information about this.

I know that this is still only in CTP and a lot of functionality is missing, but I'm just looking for input / guide information at this point.

Answer 1

Since .NET 4, including EF4, is beta 1, you will not get any useful general answer at this time. For your specific case, why not check.

Create an entity model with a single object and perform some performance tests. Then expand the model to have more objects and re-run the test. If there is a performance impact on the number of objects in the model, you should see a difference in performance.

Do not forget to remove the loading effects, unless you are only interested in running applications, perform one operation and then exit.

Answer 2

Internal code only caches metadata, so once the first context has been created, you should see very few performance differences between Code-Only and EDMX.

You are right that a large number of objects can slow down EF.

Prenatal views are often recommended to support performance using large models. But this function depends on the availability of the EDMX file, so it is not surprising that it does not work with Code-Only.

However, if you find that you need to precompile the views, you can always use the ToEdmx () ​​function for CodeOnly to move from the CodeOnly world to the standard EDMX world. And, of course, once in the EDMX world, you can precompile your views.

However, this is not necessarily the approach I would take.

I think that a context with 100 or more IQueryable properties is in any case less ideal for use.

Therefore, instead of moving from codes only to representations to Gen, I would probably use the Code-Only ability to simplify the creation of smaller target subdomains to minimize the effective model size for the part of the Application that you are working on.

The result will be a series of fast, easy-to-use ObjectContexts designed for the current set of tasks.

Which IMHO is much more desirable.

Hope this helps

Alex

Answer 3

• Performance Recommendations for Entity Framework Applications
• Exploring ADO.NET Entity Framework Performance - Part 1
• Exploring the Performance of the ADO.NET Entity Framework - Part 2