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

@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.