title: Entity Framework 4: Does it make sense to create a single diagram for all entities?
body: <p>I wrote a few assumptions regarding Entity Framework, then a few questions (so please correct where I am wrong).  I am trying to use POCOs with EF 4.</p>
  
  <p>My assumptions:</p>
  
  <ul>
  <li>Only one data context can exist for an EF diagram.</li>
  <li>Data Contexts can refer to more than one entity.</li>
  <li>If you have two data sources, say MS SQL server and Oracle, EF requires two different diagrams to access the data.</li>
  <li>The EF diagram data context is the "Unit of Work", having a single Save() for anything on the diagram.  (Sure you could wrap it in a UnitOfWork class, but it essentially has the same duties).</li>
  </ul>
  
  <p>Assuming that's correct, here are my questions:</p>
  
  <ul>
  <li><p><strong>If you don't keep all entities on the same EF diagram, how do you maintain data integrity, like "Orders" cannot exist without a "Customer"?</strong>  Is this solely a function of the repository to load data just to verify integrity, or do we "try/catch" on database referential integrity errors?</p></li>
  <li><p><strong>Wouldn't you create an EF diagram for each Entity?</strong>  For example, I wouldn't expect changes to a customer and changes to a product to be written together as they have nothing to do with each other (having them on the same diagram would cause them to be written together).  Or is the scope of an EF diagram to encompass all similar entities stored in the same storage medium?</p></li>
  </ul>
  
  <p>Is it the norm to divide up the entities like that, or just have a single diagram holding all the entities?  I would think the latter, but the thinking is getting the better of me.</p>