orm - Entity Framework, application layers and separation of concerns -

i'm using entity framework 4.1 , asp.net mvc 3 application. mvc provides presentation layer, intermediate library provides business logic , entity framework sort of acts data layer guess?

i separate entity framework code set of repository classes, or appropriate variation thereof, whatever constitutes worthwhile data layer, i'm having trouble resolving design problem have.

if multi-layered approach exists me keep concerns separated, stands reason choice of data persistence should not concern of presentation layer. problem using entity framework, i'm tightly coupling application notion entity changes tracked , persisted automatically.

as such, let's in hypothetical world found reason not use entity framework , wanted swap out. well-designed solution should allow me @ appropriate layer , not have dependent layers affected, because code being written knowledge data layer tracks object changes, able swap out entity framework works in similar fashion, example nhibernate.

how use entity framework not need write code in way assumes entity changes being tracked data layer?

update still wondering issue in own scenarios:
ayende rahien wrote great article shooting down whole argument: http://ayende.com/blog/4567/the-false-myth-of-encapsulating-data-access-in-the-dal

if want continue way should give programming job , go study philosophy. entity framework abstraction of persistence , there rule of leaky abstraction says non-trivial abstraction degree leaky.

agile methodologies come interesting phenomenon: not prepare hypothetical situations. of time gold plating. each change has cost. changing persistence layer later in project costly rare. customer perspective there no reason pay part of these costs in of projects change not needed. if discus customer perspective more can should not pay @ because choosing bad api has replaced later on failure of developers / architects. refactor code regularly point needed adding new features customer wants otherwise can hardly competitive on market. of course has exceptions:

• customer wants (or architecture demands reason , customer agrees it) such abstraction. in such case must count , define architecture open such changes.
• it hobby or open source project can want because not constrained resources

now problem. if want such high level abstraction should not expose entities controller. expose dtos business layer (or repositories) , add fields isnew, ismodified, isdeleted dtos. ui separated persistence architecture more complex , there no reason such complexity - on architected. way can turning off tracking (add asnotracking() each query) , proxy creation on entities (context.configuration.proxycreationenabled) - lazy loading not work well. that's throwing away of features persistence frameworks offer you.

there other points of view. recommend reading ayende's recent posts repository , comments sharp architecture.