title: Bounded (Db)Contexts in Entity Framework Architecture
body: <p>I have just watched Julie Lermans videos about using bounded contexts in EF (http://www.pluralsight.com/training/Courses/TableOfContents/efarchitecture) and I am now trying to work out the best way of implementing it (using POCOs). The two options I see are to either have one edmx model that defines everything and then handcraft the DbContexts to include the appropriate entities, or to have separate edmx models for each context and use the automatically created DbContexts.</p>
  
  <p>Has anyone any ideas of which is best or any pros/cons of either?</p>
  
  <p>IMHO: 
  For a single model it is a lot less classes and a lot more code re-use (though these classes are created automatically so really it will only be the extra functionality that will manually be duplicated), but I will have a lot of classes in one place and for classes that need to be specialised these will each have to have different names. E.g. Customer, CustomerForFunctionalityX, CustomerForFunctionalityB.</p>
  
  <p>With the separate models I can be much more stringent on what goes into a context as removing a property doesn't need to be a completely new entity, and I can name everything as I wish (i.e. all models can use a Customer object even if it differs between models), but now each context has entirely different entities even if they are all just mapping to the same table - which can also make it more difficult to pass them between contexts (this however shouldn't be needed too often otherwise it means the contexts have been defined wrong).</p>