如果框架不持有持久性,则我的单元测试能够在实体模型下构建一个文件系统版本的持久化存储吗?
我肯定会在GUI中使用实体框架的模型首要功能,因为对于我的开发人员来说,进行模式更改并保持数据访问层同步太容易了。
有人尝试过使用模型优先方法并添加持久性无知吗?
我认为这将是我理想的建模世界。 我目前使用LINQ2SQL,但在交换数据存储时有一些棘手,但是有一个不会隐藏在一组业务线IDataContext接口后的自动丰富数据层。
如果我能看到一些这个工作的场景,我将来愿意投入更多时间来尝试。
如果框架不持有持久性,则我的单元测试能够在实体模型下构建一个文件系统版本的持久化存储吗?
我肯定会在GUI中使用实体框架的模型首要功能,因为对于我的开发人员来说,进行模式更改并保持数据访问层同步太容易了。
有人尝试过使用模型优先方法并添加持久性无知吗?
我认为这将是我理想的建模世界。 我目前使用LINQ2SQL,但在交换数据存储时有一些棘手,但是有一个不会隐藏在一组业务线IDataContext接口后的自动丰富数据层。
如果我能看到一些这个工作的场景,我将来愿意投入更多时间来尝试。
实体框架不具备真正的持久性无知。这是最大的批评之一(即强制基类、许多EF联系等)。LINQ-to-SQL可以具有持久性无知,但实际上人们倾向于使用延迟加载和属性方法,这意味着它仍然不具备持久性无知。
关于持续性,即使是无神论者,它(EF)仍需要一个提供者。如果您想编写一个与文件系统对话的EF提供者,那就继续吧!尽管这需要大量的工作,使用SQL Express数据库(平面文件)等将更容易一些。
只是更新一下,这已经在Entity Framework 4.0中改变了,它支持持久化无关性。