title: ORM Entities vs. Domain Entities under Entity Framework 6.0
body: <p>I stumbled upon the following two articles <a href="http://www.sapiensworks.com/blog/post/2012/04/20/Dont-Use-ORM-Entities-To-Model-The-Domain.aspx" rel="noreferrer">First</a> and <a href="http://www.sapiensworks.com/blog/post/2012/04/07/Just-Stop-It!-The-Domain-Model-Is-Not-The-Persistence-Model.aspx" rel="noreferrer">Second</a> in which the author states in summary that ORM Entities and Domain Entities shouldn't be mixed up.</p>
  
  <p>I face exactly this problem at the moment as I code with EF 6.0 using the Code First approach. I use the POCO classes as entities in the EF as well as my domain/business objects. But I find myself frequently in the situation where I define a property as public or a navigation property as virtual only because the EF Framework forces me to do so.</p>
  
  <p>I don't know what to take as the bottom line of the two articles? Should I really create for example a CustomerEF class for the entity framework and a CustomerD for my domain. Then create a repository which consumes CustomerD maps it to CustomerEF do some queries and than maps back the received CustomerEF to CustomerD. I thought EF is all about mapping my domain entities to the data.</p>
  
  <p>So please give me some advice. Do I overlook an important thing the EF is able to provide me with? Or is this a problem which can not completely solved by the EF? In the latter case what is a good way to manage this problem?</p>