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

Question

如果框架与持久性无关，我的单元测试能否在我的实体模型下构建持久性存储的文件系统版本？

我肯定会在 GUI 中使用实体框架的模型优先功能，因为我的开发人员很容易进行架构更改并保持 DAL 层同步。

有没有人尝试过使用模型优先方法并添加持久性无知？

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

如果我能看到这个工作的一些场景，我想在未来投入更多时间来尝试这个。

Answer 1

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

保持持久性不可知 - 它（EF）仍然需要提供者。当然，如果您想编写一个与文件系统对话的 EF 提供程序，请继续！不过，这将是一个大量的工作。使用 SQL Express 数据库（平面文件）等会更容易。

Answer 2

只是一个更新，从支持 Persistence Ignorance 的 Entity Framework 4.0 开始，这已经发生了变化。