Then, should I write a data access layer or not?

Danny and I appear to be giving inconsistent advice on this regard in our recent weekend posts:

• Danny: More about how to fit the ObjectContext into apps
• Diego: Unit Testing your Entity Framework Domain Classes

In reality, I think we had different scenarios in mind.

Danny is talking about the general case, and he is absolutely right that the benefits of creating an encapsulated data access layer have diminished dramatically because of the Entity Framework. EF now provides a complete abstraction layer that isolates application code from the store and from schema differences.

For many applications, ObjectContext is going to be the data access layer.

But in my opinion, the benefits of the TDD approach and of Persistence Ignorance are reasons you may still want to go the extra mile. Also, there is an argument for avoiding having code that depends on a certain persistence technology all over the place.

Whether the guidelines I am suggesting are enough, I would say it is a work in progress. Roger already noticed some inconsistencies in them (I wish I knew what the inconsistencies are in his opinion!).

Moreover, Danny and I have participated in some conversations on ways to "have your cake and eat it too" when it comes to seamless use of TDD on EF.

Edit: Added some context and corrections.