Is Entity Framework good for bigger Database?

Question

I used Entity framework with a database having around 50 tables and it worked just fine.

But just to see what happens with a larger database in terms of number of tables/entities i tried to implement the Entity Framework to a database that had around 100+ tables. Once i selected all the tables and clicked on the Finish Button on the Entity Framework Wizard its just hanged my VS 2010 so i could not get any results.

My Questions are as below;

1.If I have larger Database in terms of Table/Entites as described above, Is it a good idea to use Entity Framework?

2.What will be the better approch using Entity Framework to work with database?

3.Should i create multiple DataContext or EDMX files with lesser entites in it?

4.How will these different DataContext interact with each other?

5.Is there any recommended no of tables that should be used while working with Entity Framework?

Answer 1

EF, probably yes. The toolset in Visual Studio? Not so much, apparently. For a database this big, you might want to do Code First.

Answer 2

I think EF itself have't performance limitations for count of tables, but have for count of records in particular table. You have to do manual object-db relation (i.e. manual write classes for tables and corresponding attributes) for go away from design problems in VS10. It's clear approach in Hibernate, but in EF probably not.

Answer 3

Entity Framework is the best way to develop database applications. I used to develop my applications using LINQ to SQL but since Microsoft is not going to support it in future, it recommends to use Entity Framework. By the way, Entity Framework 4 in .NET 4 has much better performance than previous versions. I'm currently developing an enterprise application using Entity Framework and it supports all my needs. I suggest to use Entity Framework.

Answer 4

@Will is correct that the limitation you're seeing is in the designer, but it's not the only one, so Code-First doesn't necessarily fix the problem.

If the designer seems slow, it's inconvenient, but not the end of the world. Runtime performance considerations are another thing altogether. For performance-critical tasks and tuning, you'll want to understand the whole pipeline.

View generation, e.g., takes time. You can move this to compile time with manual work.

1.If I have larger Database in terms of Table/Entites as described above, Is it a good idea to use Entity Framework?

I certainly wouldn't let it stop you.

2.What will be the better approch using Entity Framework to work with database? 3.Should i create multiple DataContext or EDMX files with lesser entites in it?

That's certainly a good approach for many applications.

4.How will these different DataContext interact with each other?

Mostly not. A single, giant data model is often a bad idea due to service coupling. However, you can selectively couple them by sharing portions of the models with includes in EDMX or classes in code-first.

5.Is there any recommended no of tables that should be used while working with Entity Framework?

One way is to use smaller models, as you've suggested. Another way is to work around the runtime performance issues which sometimes come with larger models (see the links I give above). Like any potential performance "problem", write correct code first, then profile and fix the slow parts. Usually, query tuning is more important than model size anyway.