Persistence Ignorance in the Entity Framework

The ADO Entity Framework seems to take us a certain part of the way, but not all the way, to what Fowler calls "Persistance Ignorance". That is, ideally, one would like to be able to establish a domain layer that contained entities that are in no way aware of the underlying persistence mechanism being used. This would allow one to easily replace the actual data access layer without being concerned about this affecting the domain layer. With the ADO.Net Entity Framewok I see two main violations of this principal that, as far as I can tell, cannot be circumvented: 1. Entities must subclass the Entity framework class, and 2. It is necessary to attach various attributes to entity properties. I can live with (1); with the appropriate discipline, one can avoid any functional dependence on the parent class from within the domain layer. If later I decide to use another persistence mechanism than ADO, I can easily remove Entity from the inheritance tree. Item (2), on the other hand, is much more troublesome and I can't see why attaching these attributes is strictly necessary. Notwithstanding the Data Contract attributes, all of the information encapsulated by these attached attributes is derived from information contained in the CSDL file - which is available at runtime via the metadata workspace. (By the way, are these data contract attributes required?) These considerations lead to the following questions: 1. Why is it necessary to redundant metadata (information that is both in the CSDL and attached as attributes); why can't the single source of this information just be the CSDL specification? 2. Was the concept of "persistence ignorance" considered when the framwork was being designed? If so, why weren't the tenets of this principal followed more closely? 3. Am I missing something? Is there some construct that would allow complete (or even allow one to come closer to) PI? Is there any way I could create a domain class that has no dependency at all on the entity framework and yet still have persistence services be managed by the framwork provided the CSDL, MSL and SSDL are specified? I think what you guys are doing here is really cool, interesting and useful; I just wish your approach allowed complete independence of one's domain layer from persistence infrastructure