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