Entity Designer: Speed up & Optimize for using with ~200+ entities
Entity designer is practically useless with non trivial models (for enterprise applications). Generate model from DB with more than 200 tables with FKs (I have tried on 350+ 9Mb edmx), and try to move entities and so on. It is nightmare.
Possible improvements:
1) Profile and optimize :)
2) To have option: To show or Not relationships.
3) To have option: Display or not fields in table.
4) To have subject areas: Render only subset of tables.
5) Separate model to several edmxs and have ability setup relations between entities from different edmxs.
6) To explore tools like ErWin, Power Designer and so on and fined other ideas.
AdminMike Flasko
(Lead Program Manager, DataFx)
shared this idea
18 comments
-
Anonymous
commented
I would like to see something like what is described in #5 "Separate model to several edmxs and have ability setup relations between entities from different edmxs." I would like to additionally request a high level design surface that lets you view different namespaces or edmxs as related packages that you can drill down into to see the design surface for that particular namespace.
-
zoidberg
commented
There should also be Multi Touch support. It would be very nice to browse and design your Entitiy Diagrams with a touch device as the Surface Pro.
For this of course this has to be very fast. -
Mark
commented
At some point I hope the UI can be separated from the metadata in the edmx files. Merging an edmx file is an extremely painful process. Most times we don't even bother merging. Just take one version and reapply the changes to it.
-
Andrea Piccioni
commented
If may be useful for testing, we've one emdx with 800 entity. We are testing it and we are profiling the performace.
We are using "pre-generated views" (otherwise is impossible) as described at this link: http://blogs.msdn.com/b/appfabriccat/archive/2010/08/30/solving-the-no-logical-space-left-to-create-more-user-strings-error-and-improving-performance-of-pre-generated-views-in-visual-studio-net4-entity-framework.aspx
I think that the new feature called "Multiple Diagram Support" could help us and at the same time implicitly drive us to a large model, therefore the performace problem of "large model" become prioritary.
Thanks -
Kram
commented
Two more absolute MUST haves:
7) Separate the designer coordinate code from the model specifications. Source versioning systems cannot avoid conflicts in team development scenarios. Our inability to merge frequent changes to 5 or more versions of the same edmx file makes EF unusable for us right now.
8) Provide unlimited segregated EDM design diagrams a la SQL Server Database Diagrams. FK relationships would extend to entities not on a particular diagram. 200 entities on a single EDM designer is worthless. -
Konstantin Tarkus commented
Daniel Kress, you can open model viewer (a list with all model entities, they are listed in alphabetical order, right click on one > show in entity designer).
-
Daniel Kress
commented
It's really a problem. An alternate way to solve it might be to use selective diagrams where you can choose tables to display like SQL Server Management Studio does. You can't find something on a designer anyway if there are a lot of tables, no search etc.
-
Rodolfo Reichart
commented
The idea expressed in point 5 could be a great improvement. It's a big limitation when working with more than 200 entities!
The possibility to work with separated EDMXs, maintaining the relations, could be used to re-utilize a part of the model in another project. -
I guess it's hard to implement with single .edmx file. As an alternative EF team could create a designer (enhanced class diagram) for Code-First POCO classes: http://data.uservoice.com/forums/72025/suggestions/1547469
-
Erkan Maraş
commented
Most imported Suggestion for big project.
-
Alexander Kot
commented
2 David Veeneman:
Sometimes DB model cannot be changed -> EF will not be used but NHib will (It's EF problem not problem of DB model).
Define all in 1 single model - it goes again all architecture pattern like coupling \cohesion -> EF will not be used in Big projects.
-
AboOmar
commented
Really the EF team must take these improvements into account in the next release
-
AboOmar
commented
Really the EF team must take these improvements into account in the next release
-
AboOmar
commented
Really the EF team must take these improvements into account in the next release
-
Abhishek Jain
commented
I believe this is most important aspect for EF engineers to work on. Otherwise it would be impossible for developers to use EF on large enterprise database
-
Jim656
commented
EF startup performance with large database is horrible, it seems it loads all the metadata at one time. With large database, we have to split into several data model, as sequence, we are not able to establish relationships between entities.
-
Adam
commented
My vote would be to:
1) Improve EF startup performance. The first EF call in models with 100+ tables can take more than 30 seconds depending on the computer. Note: The views are pre-generated using the EdmGen command line tool.
2) If EF startup times cannot be improved, provide a clean way in the EF designer to create smaller edmx files/ models. If possible, provide a way to create relationships across models. -
David Veeneman
commented
Just a thought: 200 entities seems like a lot, for even an enterprise model. I'd suggest that the model needs some serious optimization work. Perhaps there are a lot of value objects that have been given entity status.
