Menu
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.
270
YES, EF DOES PERFORM JOINS IN MEMORY IF it has a set of values that are provided as a part of query or an in memory list, basically for anything that is not from the database, EF will pull everything from the database, perform the operations in memory and returns the results.
You can create such a relationship by defining a third table, called a junction table, whose primary key consists of the foreign keys from both table A and table B.
Yes, and you'll find a number of nice features well suited toward rapid application development. That said, it's somewhat of a half baked technology, and lacks many advanced features of its own predecessor, LINQ to SQL (even 3 years after its first release).
Entity Framework (EF) Core is a lightweight, extensible, open source and cross-platform version of the popular Entity Framework data access technology. EF Core can serve as an object-relational mapper (O/RM), which: Enables . NET developers to work with a database using . NET objects.
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.
176
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.
28
I'm sure not all 1000+ tables are related. Break it up into logical pieces.
24
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
