title: Business concerns vs persistence concerns
body: <p>I am using Entity Framework to handle persistence between my core model and the database. I cannot see a way of satisfactorily working with EF without compromising my domain entities just to enable persistence. I really want to implement a rich domain model which is truly ignorant of how it's state gets stored.</p>
  
  <p>For example, the EF convention is to map multiple relationships to virtual ICollections. I realise that I could make the member protected, but this won't work if the core model and the EntityTypeConfigurations are in different assemblies.</p>
  
  <p>I would rather protect my model from getting into an invalid state by protecting it's associated members, preferring the following...</p>
  
  <pre><code>public class MyEntity {
  
      private ICollection&lt;Thing&gt; myThings { get; set; }
  
      public ReadOnlyCollection&lt;Thing&gt; MyThings { get { return myThings.AsReadOnly(); } }
  
      public void AddThing(Thing toAdd) { // validate, etc }
  
  }
  </code></pre>
  
  <p>Possible solutions I have identified (none of them I am really happy with)...</p>
  
  <ol>
  <li><p>Map to DTOs, and have the domain entity wrap it's attendant DTO, so the DTO has the data, and the entity has the behaviour.</p></li>
  <li><p>Move EntityTypeConfigurations into the Core assembly.</p></li>
  <li><p>Make the Core and Infrastructure.Data.Ef projects "friends" and use the internal access modifier (I really hate this idea).</p></li>
  <li><p>Accept the limitation. Leave the collections to be publically mutated and perform some other validation before they are persisted.</p></li>
  <li><p>Forget EF and go back to ADO,NET.</p></li>
  </ol>
  
  <p>Are there any other ideas? Is Persistence Ignorance an unattainable goal?</p>
  
  <p>Thanks!</p>