title: Entity Framework, application layers and separation of concerns
body: <p>I'm using the Entity Framework 4.1 and ASP.Net MVC 3 for my application. MVC provides the presentation layer, an intermediate library provides the business logic and the Entity Framework sort of acts as the data layer I guess?</p>
  
  <p>I could separate the Entity Framework code into a set of repository classes, or an appropriate variation thereof, whatever constitutes a worthwhile data layer, but I'm having trouble resolving a design problem I have.</p>
  
  <p>If the multi-layered approach exists to help me keep concerns separated, then it stands to reason that my choice of data persistence should also not be a concern of the presentation layer. The problem is that by using the Entity Framework, I'm basically tightly coupling my application to the notion that entity changes are tracked and persisted automatically.</p>
  
  <p>As such, let's say in a hypothetical world I found a reason not to use the Entity Framework and wanted to swap it out. A well-designed solution should allow me to do this at the appropriate layer and not have dependent layers affected, but because all code is being written with the knowledge that the data layer tracks object changes, I would only be able to swap out the Entity Framework for something that works in a similar fashion, for example nHibernate.</p>
  
  <p>How do I get to use the Entity Framework but not need to write my code in a way that assumes that entity changes are being tracked by the data layer?</p>
  
  <p><strong>UPDATE for those still wondering about this issue in their own scenarios:</strong><br>
  Ayende Rahien wrote a great article shooting down this whole argument:
  <a href="http://ayende.com/blog/4567/the-false-myth-of-encapsulating-data-access-in-the-dal" rel="noreferrer">http://ayende.com/blog/4567/the-false-myth-of-encapsulating-data-access-in-the-dal</a></p>