Entity Framework 4 - Handling very large (1000+ tables) data models?

Question

We've got a database with over 1000+ tables and would like to consider using EF4 for our data access layer, but I'm concerned about the practical realities of using it for such a large data model. I've seen this question and read about the suggested solutions here and here. These may work, but appear to refer to the first version of the Entity Framework (and are more complex than I'd like). Does anyone know if these solutions have been improved upon in EF4? Or have other suggestions all together? Thanks.

UPDATE: After a number of attempts at making EF work, I've decided to abandon it all together for this project. Large data model support just isn't there and while there may be work arounds (e.g. editing and maintaining the xml independent of the designer), they just don't feel ready for prime time. Most problematic for me is the fact that the EF doesn't work well with the domain model spread across multiple XML files without a lot of redundancy and duplication of code. I'm still open to suggestions (I know I haven't peeled back all layers of the EF onion), but for now, I am moving on without EF.

UPDATE #2: It looks like the pending code first support (currently in EF4 CTP4) is likely to end up being the solution we want as it takes the designer and large XML file maintenance out of play.

Answer 1

You should definately take a look at LLBLGen Pro v3. While LLBLGen is another O/RM tool, just like EF is an O/RM tool, the latest version contains a designer that allows you to generate models for LINQ to SQL, NHibernate, AND Entity Framework (both 1.0 and 4.0). Its designer is pretty solid and has better support for big domain models.

Answer 2

The number I heard in a Microsoft screencast is a maximum of roughly 250 tables per EF model. That doesn't mean EF can't handle more - it might just be sensible to break up your 1000+ tables into several logical groups of tables, and use one EF model per such logical group (with up to 250 tables in it).

I highly doubt you'll have queries that will need to use all 1000 tables at once - most likely not even 10 at once. So you should definitely be able to split up your pretty large model into smaller clusters and turn each into a separate EF model.