title: Are EF objects business objects or not?
body: <blockquote>
    <p><strong>Possible Duplicate:</strong><br>
    <a href="https://stackoverflow.com/questions/217655/using-entity-framework-entities-as-business-objects">Using Entity Framework entities as business objects?</a>  </p>
  </blockquote>
  
  
  
  <p>I'm looking into using Entity Framework as an ORM, but after doing lots of reading I'm really confused as to where EF objects fit exactly.</p>
  
  <p>I was under the impression that the whole point of an ORM was to remove the drudgery and complication of mapping your object to a relational database. You load your DB and get a bunch of objects like magic. CRUD stuff all gets done against objects. If the DB changes you change the mapping but your objects stay the same.</p>
  
  <p>This would imply that you are going to use these objects throughout the system, and that they will have behaviour. They are business objects. This makes sense to me, and indeed MS <a href="http://msdn.microsoft.com/en-us/library/cc716789.aspx" rel="nofollow noreferrer">tells you how to add behaviour</a></p>
  
  <p>However, I've been reading lots of people saying that your should never use EF objects as your business objects as they are concerned with persistence of data only, and would couple your business objects with EF. They suggest using EF as an abstraction of the data layer, and mapping them to real business objects.</p>
  
  <p>This seems pointless to me. Why do I need yet ANOTHER abstraction layer when I still end up mapping to my business objects? If I have to map EF properties, I might as well map DB columns!</p>
  
  <p>I thought the whole point of an ORM was to automate the mapping and act as an abstraction over the backing store? Am I missing something?</p>
  
  <p><strong>EDIT:</strong> By behaviour I mean business logic. Validation, calculated properties, business methods etc.</p>