模型类中的虚拟属性如何违反持久性无知原则？答案

【问题标题】：How could virtual properties in model classes violate the persistence ignorance principle?模型类中的虚拟属性如何违反持久性无知原则？
【发布时间】：2020-07-23 03:03:15
【问题描述】：

我刚刚阅读（修订）了一些架构原则（如此处记录的 https://docs.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles）并且对 persistence ignorance 原则有这样的违规示例感到有点困惑：

 Properties requiring virtual keyword

所以我不清楚为什么这样的要求会违反持久性无知原则。假设我们的模型类只是 C#，由 .NET 编译器编译。要加载模型实例，只需正常创建类实例（所有属性都从相应的持久数据初始化，例如：数据记录）。要保存它，只需从模型实例中读取值并将其放回持久存储（任何类型的）。

实际上Entity Framework 确实需要启用一些很酷的功能，例如延迟加载……而且我确实看到 EF 在支持各种持久性存储（数据库）方面做得很好，据我了解应该与所谓的a violation of the persistence ignorance principle相反。

你能给我一些真实的例子来证明requiring virtual properties 可能违反持久性无知原则吗？如果有的话，那是不是有时我们不能只遵守所有的原则，我们可能不得不在遵循好的原则和拥有好的特性之间进行权衡（就像 EF 一样？

【问题讨论】：

标签： c# architecture principles

【解决方案1】：

它违反持久性无知原则的原因很简单：您必须使属性virtual 使EF 满意，因此您将业务代码二重奏更改为持久性关注点。除了直接违反原则之外，使用覆盖类成员的 EF 功能会更改类的类型，因此，例如，在您的 Equals 实现中，您不能再使用 GetType() 来比较两个实例，因为对象的实际类型是由 EF 在运行时生成的，因此，您再次根据持久性问题开始更改域逻辑。另外，我还建议不要在大多数情况下使用 EF 的延迟加载，因为它只能同步工作，阻塞当前线程。

【讨论】：

you changed the business code duo to a persistence concern 是什么意思？实际上，我看到 virtual 不会影响此处与持久性存储相关的任何内容，但我在您的回答中没有看到任何解释这一点的线索。 lazy loading 只是virtual 启用的功能之一。许多框架都需要它来拦截属性访问并执行自定义逻辑，而不仅仅是Entity Framework。逻辑位于 C# 类中（在框架中），不应影响数据（持久性）。
@Hopeless 改变本身与持久性无关。您对业务代码执行更改的原因是 EF 的要求（这是应用程序的“持久性”方面）。原则背后的想法是，在编写业务代码时，您根本不应该考虑持久性。 virtual 关键字改变了您的业务代码的行为：您现在可以覆盖派生类中的属性，如果这是您想要的，这很好，但如果它不是出于业务意图，它不应该影响业务代码，根据校长。
所以你的意思是persistence 这里是代码行为/逻辑而不是数据存储（如persistent store）？好吧，我确实认为这不是明确指出just ignore the persistence 的原则的意思。如果按照您的方式理解，我们应该将persistence ignorance 变成persistence cognizance 之类的东西。
@Hopeless 我不确定你的意思。当然persistence 指的是实体商店。但我认为您将database-agnostic 代码与persistance ignorant 代码混淆了。 EF 与 DB 无关，但它仍然是一种持久性机制。 persistance ignorance principal 指出，建模领域概念的类不应影响，因为它们可能会被持久化。在编写领域代码时，您应该能够完全“忘记” EF，因为它与您系统的业务逻辑无关。
so persistence 这里指的是使用模型类来存储数据的框架层，如 EF、NHibernate、Dapper、ADO.NET ......实际上，原始文档中有一行让我感到困惑Persistence choices might change over time, from one database technology to another。它谈到了database technology，这让我想到了诸如 SQL Server、Oracle 之类的东西……如果是这样，我会说从这个持久性框架切换到另一个框架需要付出一些努力（例如从 EF 到 NHibernate，反之亦然) ...