<p>If the framework is persistence agnostic, can my unit tests construct a file system version of the persistance store underneath my entity model?</p>

<p>I'll be using the model first features of entity framework in the GUI for sure because it's too easy for my devs to make schema changes and keep DAL layer in sync.</p>

<p>Has anyone tried using the model first approach and adding persistence ignorance?</p>

<p>I think this would be my ideal modelling world. I use LINQ2SQL atm and it's a bit tricky to swap out the data store yet have an automatically rich data tier that doesn't hide behind a set of business line IDataContext interfaces.</p>

<p>If I can see some scenarios of this working, I'd like to invest more time in the future to try this out.</p>

Entity Framework does
not
have true persistence ignorance. That is one of the biggest criticisms (i.e. a forced base class, lots of EF ties, etc). LINQ-to-SQL
can
have persistence ignorance, but in reality people tend to use the lazy loading and attributed approach, which means that it still doesn't have persistence ignoance.
Re being persistence
agnostic
- it (EF) would still need a provider. Sure, if you want to write an EF provider that talks to the file system, go ahead! It would be a
lot
of work though. It would be easier to use a SQL Express database (flat file) etc.