>Honestly I don't see how the EF benefits a large, complex fat-client app with a data store that has hundreds of tables ( thousands of columns ). If you have to generate a CSDL file for every combination of entities you plan on querying back then you have lots of work ahead of you compared to someone with good meta data on their data store ( relationships etc.. ) and generating queries in code and submitting them via good ole' ADO.Net. The someone who has to generate those XML files still has to know the relationships in the data store.



the generation of those file is automatic. They can be updated when the base changes. It takes about 5 minutes to create a complex data mode and then the real power is in customizing the EF Data on the program side to make your life easier. The translation to the Database side is automatic once set up. There is power in the EF and I know of a few companies who are using it in production for large tables. We considered it here for our app which has roughly 150 tables and 1,000's of stored procs. The current version of the EF (which will be rectified in the next release) has poor support for stored procs and a few security holes unless you are using ADO .Net data services as the transport.