ADO.NET实体框架中的持久性无知是否意味着我认为它意味着什么？

Question

如果框架是持久性不可知的，我的单元测试可以在我的实体模型下构建一个文件系统版本的持久性存储吗？

我将在GUI中使用模型的实体框架的第一个功能，因为我的开发人员很容易进行模式更改并使DAL层保持同步。

有没有人尝试使用模型第一种方法并添加持久性无知？

我认为这将是我理想的建模世界。我使用LINQ2SQL atm并且交换数据存储有点棘手，但是有一个自动丰富的数据层，不会隐藏在一组业务线IDataContext接口后面。

如果我能看到一些有效的方案，我想在未来投入更多时间来试试这个。

Answer 1

只是一个更新，现在已经从支持Persistence Ignorance的实体框架4.0发生了变化。

Answer 2

实体框架确实不具有真正的持久性无知。这是最大的批评之一（即强迫基类，大量EF关系等）。 LINQ-to-SQL 可以持久性无知，但实际上人们倾向于使用延迟加载和归因方法，这意味着它仍然没有持久性的忽略。

重新持久性不可知 - 它（EF）仍然需要提供者。当然，如果你想写一个与文件系统对话的EF提供者，那就继续吧！尽管如此，这将是很多的工作。使用SQL Express数据库（平面文件）等会更容易。