New Posts New Posts RSS Feed: Separating EDMX - Any Guidelines or Best Practice?
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Separating EDMX - Any Guidelines or Best Practice?

 Post Reply Post Reply
Author
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391
Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Topic: Separating EDMX - Any Guidelines or Best Practice?
    Posted: 08-Oct-2008 at 10:39am
Hi Sebastian,
 
This is a great question which, as you know, we're struggling with too.  You may want to also post your question to the MSDN forum covering Entity Framework, since the problem is not DevForce-specific.  That forum is at http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=533&SiteID=1.
 
Back to Top
sebma View Drop Down
Groupie
Groupie
Avatar

Joined: 19-Aug-2008
Location: Singapore
Posts: 66
Post Options Post Options   Quote sebma Quote  Post ReplyReply Direct Link To This Post Posted: 08-Oct-2008 at 12:48am
Hi all,
 
Is there anyone like to share, in a real-world scenario, where there can be more than 50 entities and beyond, how entities can be "normalized" into different EDM "packages/modules", i.e. different edmx files.
 
Theoretically, if we were to split edmx, either in one assembly or in separate assembly, the "normalized" edmx would contain the only entities "of interest" in its module/package.
Let's say after design phase we have Order and Supplier packages, where each package houses it own entities/classes. 

The issue I can think of is when Order associates Supplier(which is in another edmx or assembly) for example, we may end up with duplicate Supplier type because it comes from the same database table. Having Supplier type in 2 assemblies can result in ambiguity. Even if we use namespaces, client-side developer could be confused.
 
In addition, we then need discipline to only maintain Supplier from its original edmx/assembly. Order edmx/assembly may also later update model from database. Though you can select what tables not to update, it is still lots of careful detailed handling, which is error-prone.
 
Any ideas to share are welcomed!
 
Best regards
Sebastian
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down