持久性无知通常定义为持久性和检索标准.NET对象(或如果您真的坚持给它们命名的话,则为POCO)的能力。 seemingly well accepted definition of a standard .NET object是:
但是,我看到有人将NHibernate描述为允许持久性无知的框架,但是它不能在任何标准.NET对象(仅符合特定设计要求的标准.NET对象)上工作,例如(source):
现在,尽管类本身没有任何特定于持久性框架的属性或基类等,但对我而言,它并不是真正的“持久性无知”,因为它必须遵循一组设计准则,以方便所选持久性框架的使用。您必须考虑到持久性框架的要求来设计和实现类。如果您不了解它,则该类可能无法使用。
我对“持久性无知” /“POCO”的定义感到困惑的地方是,从概念上讲,我看不出这与添加诸如
[Serializable]
或[DataContract]
或[XmlType]
或任何其他持久性框架之类的属性有何不同特定的注释,使用该框架有助于实体的持久性和检索。那么,“持久性无知”到底是什么?
显然,将其定义为能够保留“普通类”是一个谬误,因为NHibernate只是在不引用特定于框架的类的范围内是普通的,而它们是非凡的,因为它们需要非常规的设计选择,例如默认构造函数和所有-虚拟成员和可变类型上的Equals / GetHashCode实现。
因此,当对象促进持久性框架的使用(在设计和结构中或通过使用特定于框架的批注)但自身不执行任何持久性逻辑时,说“持久性无知”是否成立是合理的吗?
最佳答案
与大多数事物一样,我会说它是一个可伸缩的标尺。我们制造的某些东西想要具有持久性。在规模的一端,这是一种具有所有内脏,依赖关系和代码的东西,这些东西都是定制的,可以以特定的方式仅保留这一件事。另一方面,这只是神奇地发生的事情,没有我们要做的事情还不止是添加 token 或在某个地方设置导致该事情“持续存在”的属性。为了达到天平的魔幻般的一面,有一些框架,设计准则,约定等可以辅助魔幻的发生。我认为您可以争辩说,可以生产出比NHibernate要求和限制更少的工具,但追求相同的目标。假设的工具将沿着我们的规模发展。
我不知道我这么喜欢“持久性无知”一词。它实际上是关于对象不了解实现,后备存储,高速缓存之类的东西的-对象通常知道它是否是持久性的。但这仅仅是语义。