究竟什么是"持久性无知"？

Question

持久性无知通常被定义为持久化和检索标准.NET对象的能力(如果您真的坚持给它们命名,则为POCO).一个看似公认的标准.NET对象定义是:

"...普通的课程,你专注于手头的业务问题而不添加与基础设施相关的原因......"

但是,我看到人们将NHibernate描述为一个允许持久性无知的框架,但它是一个不能在任何标准.NET对象上工作的框架,只有符合特定设计要求的标准.NET对象,例如(源代码):

• 所有类都必须具有默认构造函数
• 除非打开类并且所有成员都是虚拟的,否则某些功能不起作用
• 除非您滥用Equals/GetHashCode,否则对象标识无法正常运行

(旁白:在任何人不高兴之前,我并不打算在这里选择NHibernate,它只是一个经常被引用的框架示例,据说允许持久性无知.我敢肯定类似的论点可以应用于其他声称相同的ORM .)

现在虽然这个类本身没有任何持久性特定于框架的属性或基类等,但对我而言,它实际上并不是"持久性无知",因为它必须遵循一套设计指南以便于所选持久性框架的使用.您必须考虑到持久性框架的要求来设计和实现该类; 如果你不了解它,那么这个班可能无法使用它.

当我在与"持久性无知" /"POCO"的定义问题是,我不知道怎么样,从概念上讲,这是真的有什么不同,以添加属性,如[Serializable]或[DataContract]或[XmlType]或任何其他持久性框架,具体的注解这有利于使用该框架的实体的持久性和检索.

那么,"持久性无知"到底是什么？

很明显,将它定义为能够持久化"普通类"是一种谬误,因为NHibernate只是在没有引用特定于框架的类的情况下是普通的,而它们非常特殊,因为它们需要不寻常的设计选择,例如默认构造函数和所有类-virtual成员和可变类型的Equals/GetHashCode实现.

因此,当对象促进使用持久性框架(在设计和结构中或通过使用特定于框架的注释)但不执行任何持久性逻辑时,"持久性无知"是否合理？

Answer 1

我会像大多数事情一样声称它的滑动比例.有些东西我们想要拥有持久性的属性.在规模的一端是这个东西具有所有的内容,依赖关系和自定义构建的代码,以便以特定的方式坚持这一件事.在规模的另一端是神奇地发生的事情,所有这些都没有我们做的更多,只是添加一个令牌或设置一个导致该东西"只是持久"的属性.为了达到规模的神奇面,有框架,设计指南,惯例等可以帮助实现魔法.我认为你可以争辩说,可以生产一种工具,它比NHibernate具有更少的要求和限制但追求相同的目标; 这个假设工具将沿着我们的规模进一步发展.

我不知道我非常喜欢"坚持无知"这个词; 它实际上是关于一个对象不知道实现,后备存储,缓存,那种东西 - 一个对象通常知道它是否是持久的.但这只是语义学.

Answer 2

我不相信你对"坚持贪婪"的理解(或定义)是错误的.

在真正的问题是,漏抽象.很简单,现有技术使得实现真正的PI 变得非常困难.