views:

34

answers:

1

We have a database app that we're beginning to write some new systems for and I want to redo our DAL, potentially using EF4. As I begin to look at this, it seems that it's a bad idea to just use a single EDMX file for my entire database. When I did this, here is a screenshot of what that looks like (zoomed out as far as I can zoom out) to give you a bit of an idea.

So it seems that I should break this down into multiple EDMX files. Where can I start to learn a good strategy for doing this?

Thanks!

+2  A: 

There is nothing to learn at the basic level. Subset your screens and problems down to a reasonable level of complexity and use a EDMX for each section or part of your application.

At the most complex level you'll need to understand all about how the "spaces" work ( C-Space, S-Space, O-Space ) and how to create ObjectContexts with custom configuration.

jfar
I don't understand what you mean by `understand all about how the "spaces" work` - what does this mean? What you said about breaking things down into a manageable level of complexity is what I expected but this brings what seem to be obvious questions to mind: 1) If I have overlap across two different EDMX (such as a Person table), what issues will I run into and how do I deal with them? 2) Is the best way to break this down by domain relevance or is there a better way to do it?
Jaxidian
Sorry, my first few Google attempts failed with the Spaces stuff but then I stumbled upon this: http://blogs.msdn.com/alexj/archive/2009/04/03/tip-10-understanding-entity-framework-jargon.aspx
Jaxidian
Well you asked "start to learn a good strategy" so I mentioned those. Thats where all the merging and sharing complexity is so thats where I would start. If you find tutorials about merging two edmx files and don't understand the spaces you'll be lost.
jfar