Does the DevForce Object Mapper work with individual metadata files (csdl,ssdl,msl) instead of an EDMX file?

I'm trying to create multiple data models from a single, very large database.  I need to have a couple of tables in both models so I've been looking at the "CSDL Using Namespace" technique where you work with the individual metadata CSDL, MSL and SSDL files separately (as "Using" isn't supported in the EDMX designer file) and you define the common types in one CSDL file and then refer to them in the other CSDL files.  You then have to generate the C# types for each model using EdmGen.exe and refer to both CSDL files in the metadadta connection string.  This info comes from: http://blogs.msdn.com/adonet/archive/2008/11/25/working-with-large-models-in-entity-framework-part-2.aspx

We are in the same boat.  My hope is that the "large model" issues mentioned in Part I and Part II of the ADO.NET team blog will be addressed in the upcoming EF4/ VS 2010 release.  I just posted this on the ADO.NET blog site today:

Will any of the "large model" issues mentioned in Part I and Part II be addressed in the upcoming EF4 release?  There is a lot of good information about some of the new features, but can you let us know if there is any movement towards making EF more friendly to large models?  Or at least if there will be a less manual approach to splitting models in EF4? 

My team is in the process of migrating an application with LOTS of tables.  So far we only have ~80 tables in EF (out of 1,000+), but we will add more tables to the model as we add functionality.  Unfortunately we couldn't add all of the tables to EF due to performance problems and others issues mentioned in these blog posts.

We've tried breaking-up the model manually a few months ago, but unfortunately we encountered issues similar to "pk55".  We also ran into a few DevForce-related limitations.  However, if/when Microsoft provides better out-of-the-box support for large models/ splitting large models, I'm sure DevForce will take advantage of it. 

Anyway, a year has passed since we first started working with Microsoft EF and we are getting concerned about its ability to handle our large database.  If anyone from IdeaBlade has any inside information from the ADO.NET team, would you be willing to share?  :-)

Thanks Ward.  I appreciate your thoughtful and in-depth response.  After V1 of our product is released at the end of the year, we plan to create smaller models and will attempt to implement the solution you suggested.  We'll see how things fall-out and I'll keep you posted.  My hope was that Microsoft would be making this task easier for us in V4 of EF.  I would love to see a working version of the approach you suggested, so if IdeaBlade has any code to share it would be much appreciated.  This may help other customers/potential customers see how they can work with large databases.

I agree with you that developers should strive towards creating smaller EF models with clearly defined boundaries.  We have made a huge effort to follow just about every best-practice known to man in V1 of our software. :-)  However, I don't think Microsoft placed a "large model" limitation in EF to enforce this smaller model design practice.  In other words, it is my belief that Microsoft didn't take large models into account and unintentionally forced people to use a manual and more difficult to maintain work-around. 

By the way, I think you misinterpreted my "stiff resistance".  I do not resist the idea of a smaller model approach.  As a matter of fact, in my company's current "legacy" application we have smaller sub-domains and do not have any issues.  The resistance you detected had to do with how much time and effort we will need to spend to get this approach to work.  Shouldn't EF work the same regardless of whether or not people choose to create one large model or divide it into smaller models?  In my view this is a deficiency that will hurt Microsoft's EF offering (and possibly DevForce EF) in the long term.  I hope not, because we really love the DevForce EF product and support.  But my fear is that many larger, enterprise software companies with legacy, 1,000+ table databases may shy away from EF -- companies that I think would really benefit from DevForce.

Thanks again Ward and I'm in complete agreement.  I really appreciate the efforts you and IdeaBlade are making to assist in this area.  Like I mentioned, we hope to use the approach you suggested in the first quarter of next year, so any sample code/ guidance IdeaBlade can provide between now and then will be much appreciated!

I've read your essay and watched your video and appreciate the effort.